The overview was a bit long, and slightly inaccurate. The
ClientHelloInner is encrypted after (most) of the ClientHelloOuter is
constructed. I've also merged the ECH-naive server case with the ECH
rejection case. This is more consistent with the client text, and most
other TLS extensions, where we do not distinguish between reasons why
the extension could not be negotiated.
I've also generally tightened up the wording to make it shorter. As part
of that, I'm trimmed the repeated list of sensitive ClientHello
extensions. ECH itself is (mostly) agnostic to which extensions you
believe are sensitive, and we already gave examples in the introduction.
The overview was a bit long, and slightly inaccurate. The ClientHelloInner is encrypted after (most) of the ClientHelloOuter is constructed. I've also merged the ECH-naive server case with the ECH rejection case. This is more consistent with the client text, and most other TLS extensions, where we do not distinguish between reasons why the extension could not be negotiated.
I've also generally tightened up the wording to make it shorter. As part of that, I'm trimmed the repeated list of sensitive ClientHello extensions. ECH itself is (mostly) agnostic to which extensions you believe are sensitive, and we already gave examples in the introduction.