Code change:
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.

Related discussion:
text: 3.2. <del> ECH allows the client to encrypt sensitive ClientHello extensions, e.g., SNI, ALPN, etc., under the public key of the client-facing server.  This requires the client-facing server to publish the public key and metadata it uses for ECH for all the domains for which it serves directly or indirectly (via Split Mode).  This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to HTTPS-RR, though other delivery mechanisms are possible. In particular, if some of the clients of a private server are applications rather than Web browsers, those applications might have the public key and metadata preconfigured. When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as indicated in real-ech.  We will refer to this as the ClientHelloInner message.  The client encrypts this message using the public key of the ECH configuration. It then constructs a new ClientHello, the ClientHelloOuter, with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with an "encrypted_client_hello" extension, which this document defines (encrypted-client-hello).  The extension's payload carries the encrypted ClientHelloInner and specifies the ECH configuration used for encryption.  Finally, it sends ClientHelloOuter to the server. Upon receiving the ClientHelloOuter, a TLS server takes one of the following actions: If it does not support ECH, it ignores the "encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2. If it is a client-facing server for the ECH protocol, but cannot decrypt the extension, then it terminates the handshake using the ClientHelloOuter.  This is referred to as "ECH rejection".  When ECH is rejected, the client-facing server sends an acceptable ECH configuration in its EncryptedExtensions message. If it supports ECH and decrypts the extension, it forwards the ClientHelloInner to the backend server, who terminates the connection.  This is referred to as "ECH acceptance". </del> <ins> A client-facing server enables ECH by publishing an ECH configuration, which is an encryption public key and associated metadata.  The server must publish this for all the domains it serves via Shared or Split Mode.  This document defines the ECH configuration's format, but delegates DNS publication details to HTTPS-RR.  Other delivery mechanisms are also possible.  For example, the client may have the ECH configuration preconfigured. When a client wants to establish a TLS session with some backend server, it constructs a private ClientHello, referred to as the ClientHelloInner.  The client then constructs a public ClientHello, referred to as the ClientHelloOuter.  The ClientHelloOuter contains innocuous values for sensitive extensions and an "encrypted_client_hello" extension (encrypted-client-hello), which carries the encrypted ClientHelloInner.  Finally, the client sends ClientHelloOuter to the server. The server takes one of the following actions: If it does not support ECH or cannot decrypt the extension, it completes the handshake with ClientHelloOuter.  This is referred to as rejecting ECH. If it successfully decrypts the extension, it forwards the ClientHelloInner to the backend server, which completes the handshake.  This is referred to as accepting ECH. </ins> Upon receiving the server's response, the client determines whether <del> or not ECH was accepted and proceeds with the handshake accordingly. (See client-behavior for details.) </del> <ins> or not ECH was accepted (handle-server-response) and proceeds with the handshake accordingly.  When ECH is rejected, the resulting connection is not usable by the client for application data. Instead, ECH rejection allows the client to retry with up-to-date configuration (rejected-ech). </ins> The primary goal of ECH is to ensure that connections to servers in the same anonymity set are indistinguishable from one another.