Change:
10.1. ECH considers two types of attackers: passive and active.  Passive <del> attackers can read packets from the network.  They cannot perform any sort of active behavior such as probing servers or querying DNS.  A middlebox that filters based on plaintext packet contents is one </del> <ins> attackers can read packets from the network, but they cannot perform any sort of active behavior such as probing servers or querying DNS. A middlebox that filters based on plaintext packet contents is one </ins> example of a passive attacker.  In contrast, active attackers can <del> write packets into the network for malicious purposes, such as </del> <ins> also write packets into the network for malicious purposes, such as </ins> interfering with existing connections, probing servers, and querying DNS.  In short, an active attacker corresponds to the conventional threat model for TLS 1.3 RFC8446.

Discussion:
This PR aims to resolve the discussion in issue by: clarifying goals/non-goals for "don't stick out"; and creating a TODO for a future experiment that assesses the deployability of the GREASE extension. Dealing with PSK sticking out has been assigned to .
Rebased on top of ECH-10 changes -- addressing NAME comments next.
NAME this is ready for your second pass. I took your suggestion of substantially reducing the amount of text. It should be a bit more concise and to the point, if less precise. I didn't mean to frame GREASE this way. Can you be more specific about how the text frames it this way?
As discussed in , there are two real-ECH/grease-ECH differentiators related to the PSK extension we may wish to address. Real ECH disallows the PSK extension in ClientHelloOuter, whereas grease ECH permits PSK in ClientHello. Real ECH allows PSK in ClientHelloInner. In case of acceptance, the backend server may respond with PSK in ServerHello. The response would appear to be unsolicited. something that would not happen in a grease-ECH or vanilla handshake. The question we will ask ourselves here is if/how to mitigate these differentiators. We might simply say that clients MAY (or SHOULD?) send a dummy PSK in the ClientHello(Outer). This ought to provide sufficient cover.
I don't mind a MAY on sending a dummy PSK in case (2), though I don't think it's a good idea for case (1). The case that really matters here is when the outer and inner ClientHello both lack PSKs: Suppose the buggy network is sensitive to (1) and only allows ECH extensions when the outer ClientHello has a PSK because it knows those can't be ECH. That network has effectively broken all connections because the only way for the client to get a PSK is to have connected to the server without a PSK at some point. Suppose instead the buggy network is sensitive to (2) and breaks if the inner ClientHello has a PSK but the outer does not. The connect will fail, but between single-use tickets and bounded client session caches, the client will quickly exhaust its tickets and get out of case (2). This is a performance issue, but the connections still work.

(Though, yeah, adding the option to send a dummy one might help there. shrug)
I'm not following the following point. Could you elaborate? In any case, the case to mitigate (2) seems more compelling than the case to mitigate (1), since (2) would look like non-compliance to an ECH-ignorant network. Would be curious to see what others think.
So I think the benefit of GREASE-like strategies is that broader breakages now are more noticeable than focused breakage later. More noticeable breakage is more likely to be fixed, and less likely to make it to the ecosystem in the first place. This applies to ECH GREASE by saying we want all ClientHellos to look like ECH was deployed, so the network is less likely to develop intolerances. Differences between GREASE ECH and actual ECH thus matter because the network be intolerant to something that we failed to simulate. (1) says that, in actual ECH, all outer ClientHellos have no PSK. In GREASE ECH, some outer ClientHellos have a PSK while some do not. If we were to translate that to actual intolerance, it would mean the network rejects outer ClientHellos without a PSK. But that would break everything, ECH or non-ECH, anyway because clients don't send PSKs the first time[] they connect to a server. Clients only have PSKs to send the second time, and you can't connect a second time if you didn't connect a first time. Thus, even though (1) is a difference, it doesn't seem that difference prevents us from noticing intolerance. Agreed that mitigating (2) is more compelling than mitigating (1). [] First time overall, first time after a restart (if sessions aren't persisted), or first time after a long break (sessions expired).
I agree that (2) is more important. And I'm fine with a "MAY/SHOULD send an outer dummy PSK if you are using ECH and have an inner PSK." NAME if we were to append on a dummy PSK, what do you think would be a suitable length? (Bikeshedding over that should be fun.)

As an aside, I wanted to drill in on this point: This seems true, if we're assuming the the intolerance is "break the connection," which I think is the right interpretation. But it occurs to me that there's a slightly weaker form of misbehavior thats's possible with (1): a network may learn information about when a given client uses ECH. This seems out of scope, but maybe something to keep in mind?
Re length, I dunno leave it to the client to choose? "Probably not very long." Making that in scope sounds exceedingly difficult. For instance, for a given server, you might know that tickets issued today start with 12345 (maybe the ID of today's key), but synthesized dummy tickets won't match that.
Yep, no argument there.
Discussed in 110: Will submit a PR that says "clients MAY send a dummy PSK if the inner CH uses a PSK."
LGTM