Lessen possibility of client implementation choices undermining GREASE cover

[pkelsey]

Section 10.9.4 (Do Not Stick Out) indicates plans "to deploy GREASE ECH widely enough to disincentivize differential treatment of the real ECH protocol by the network". This implies that successfully bootstrapping ECH deployment will necessarily involve significant amounts of GREASE ECH from TLS stacks being operated in a GREASE-only mode, driven by applications that do not have a concept of how they'd configure real ECH.

Guidance on the construction of GREASE ECH is given in Section 6.2, and it involves selecting the length of the payload field based on "the size of the EncodedClientHelloInner the client would compute when offering ECH". What is the length that the client might compute when offering (real) ECH for clients that may have no sophisticated notion of offering real ECH? It seems there is plenty of room for implementations to arise which generate GREASE payload lengths that are susceptible to effective differentiation by heuristics simple enough to be within reach of the very lazy attacker of 10.9.4. Perhaps such implementations use a fixed size 'prototype ClientHello' concept, or use something highly self-similar (e.g., verbatim non-ECH ClientHello contents), or [insert other debacle]. Absent additional guardrails for GREASE ECH construction, there appears to be a risk that knowledge of the extant implementations may be sufficient to provide differentiation capabilities to an attacker who employs only single-connection passive traffic analysis.

[cbartle891]

I'm not sure what additional guardrails would suffice for a client who is already content to ignore the current guidance on constructing ECH GREASE.

[pkelsey]

The concern is not so much about clients that are ignoring the current GREASE construction guidance, but rather about the potential for clients following that guidance to wind up filling in the blanks that exist in the absence of a real ECH context in such a way that it becomes a GREASE fingerprint.

One thing that falls under this topic that isn't specifically extra guidance on GREASE construction would be requiring that when the client includes the encrypted_client_hello extension, it is placed last in the ClientHelloOuter extensions list. Doing so provides maximum ambiguity of reference for potential use of ech_outer_extensions in the EncodedClientHelloInner, which in turn prevents emergence of a future GREASE fingerprint based on the appearance of GREASE ECH earlier in the ClientHelloOuter extensions list than extensions that become commonly referenced by ech_outer_extensions in real ECH.