Change:
10.8.4. <del> The only explicit signal indicating possible use of ECH is the ClientHello "encrypted_client_hello" extension.  Server handshake messages do not contain any signal indicating use or negotiation of ECH.  Clients MAY GREASE the "encrypted_client_hello" extension, as described in grease-ech, which helps ensure the ecosystem handles ECH correctly.  Moreover, as more clients enable ECH support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting providers, the presence of ECH extensions becomes less unusual and part of typical client behavior.  In other words, if all Web browsers start using ECH, the presence of this value will not signal unusual behavior to passive eavesdroppers. </del> <ins> As a means of reducing the impact of network ossification, RFC8744 recommends SNI-protection mechanisms be designed in such a way that network operators do not differentiate connections using the mechanism from connections not using the mechanism.  To that end, ECH is designed to resemble a standard TLS handshake as much as possible. The most obvious difference is the extension itself: as long as middleboxes ignore it, as required by RFC8446, the rest of the handshake is designed to look very much as usual. The GREASE ECH protocol described in grease-ech provides a low-risk way to evaluate the deployability of ECH.  It is designed to mimic the real ECH protocol (real-ech) without changing the security properties of the handshake.  The underlying theory is that if GREASE ECH is deployable without triggering middlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECH should be deployable as well.  Thus, our strategy for mitigating network ossification is to deploy GREASE ECH widely enough to disincentivize differential treatment of the real ECH protocol by the network. Ensuring that networks do not differentiate between real ECH and GREASE ECH may not be feasible for all implementations.  While most middleboxes will not treat them differently, some operators may wish to block real ECH usage but allow GREASE ECH.  This specification aims to provide a baseline security level that most deployments can achieve easily, while providing implementations enough flexibility to achieve stronger security where possible.  Minimally, real ECH is designed to be indifferentiable from GREASE ECH for passive adversaries with following capabilities: 1.  The attacker does not know the ECHConfigList used by the server.  1.  The attacker keeps per-connection state only.  In particular, it does not track endpoints across connections.  1.  ECH and GREASE ECH are designed so that the following features do not vary: the code points of extensions negotiated in the clear; the length of messages; and the values of plaintext alert messages. This leaves a variety of practical differentiators out-of-scope. including, though not limited to, the following: 1. the value of the configuration identifier; 1. the value of the outer SNI; 1. use of the "pre_shared_key" extension in the ClientHelloOuter, which is permitted in GREASE ECH but not real ECH; [[TODO: Remove this differentiator if issue #384 is resolved by a spec change.]] 1. the TLS version negotiated, which may depend on ECH acceptance; 1. client authentication, which may depend on ECH acceptance; and 1.  HRR issuance, which may depend on ECH acceptance. These can be addressed with more sophisticated implementations, but some mitigations require coordination between the client and server. These mitigations are out-of-scope for this specification. </ins> 10.8.5.

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