Change:
SHOULD take steps to minimize or protect such requests during certificate validation. <del> 7.5. </del> <ins> 11.4. </ins> I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and <del> assess the ESNI design against them. </del> <ins> assess the ECHO design against them. </ins> <del> 7.5.1. </del> <ins> 11.4.1. </ins> <del> Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the ESNI encryption is bound to the Client Hello.  It is not possible for an attacker to "cut and paste" the ESNI value in a different Client Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. </del> <ins> Since servers process either ClientHelloInner or ClientHelloOuter, and ClientHelloInner contains an HPKE-derived nonce, it is not possible for an attacker to "cut and paste" the ECHO value in a different Client Hello and learn information from ClientHelloInner. This is because the attacker lacks access to the HPKE-derived nonce used to derive the handshake secrets. </ins> <del> 7.5.2. </del> <ins> 11.4.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys however they see fit provided each server behind an IP address has <del> the corresponding private key to decrypt a key.  Thus, when one ESNI </del> <ins> the corresponding private key to decrypt a key.  Thus, when one ECHO </ins> key is provided, sharing is optimally bound by the number of hosts that share an IP address.  Server operators may further limit sharing <del> by publishing different DNS records containing ESNIConfig values with </del> <ins> by publishing different DNS records containing ECHOConfig values with </ins> different keys using a short TTL. <del> 7.5.3. </del> <ins> 11.4.3. </ins> This design requires servers to decrypt ClientHello messages with <del> ClientEncryptedSNI extensions carrying valid digests.  Thus, it is </del> <ins> ClientEncryptedCH extensions carrying valid digests.  Thus, it is </ins> possible for an attacker to force decryption operations on the server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.5.4. </del> <ins> 11.4.4. </ins> <del> As more clients enable ESNI support, e.g., as normal part of Web </del> <ins> As more clients enable ECHO support, e.g., as normal part of Web </ins> browser functionality, with keys supplied by shared hosting <del> providers, the presence of ESNI extensions becomes less suspicious </del> <ins> providers, the presence of ECHO extensions becomes less suspicious </ins> and part of common or predictable client behavior.  In other words, <del> if all Web browsers start using ESNI, the presence of this value does </del> <ins> if all Web browsers start using ECHO, the presence of this value does </ins> not signal suspicious behavior to passive eavesdroppers. Additionally, this specification allows for clients to send GREASE <del> ESNI extensions (see grease-extensions), which helps ensure the </del> <ins> ECHO extensions (see grease-extensions), which helps ensure the </ins> ecosystem handles the values correctly. <del> 7.5.5. </del> <ins> 11.4.5. </ins> <del> This design is not forward secret because the server's ESNI key is </del> <ins> This design is not forward secret because the server's ECHO key is </ins> static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.5.6. </del> <ins> 11.4.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. <del> 7.5.7. </del> <ins> 11.4.7. </ins> <del> Assuming ESNI records retrieved from DNS are authenticated, e.g., via </del> <ins> Assuming ECHO records retrieved from DNS are authenticated, e.g., via </ins> DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See cleartext-dns for more details regarding cleartext DNS. <del> Authenticating the ESNIConfig structure naturally authenticates the </del> <ins> Authenticating the ECHOConfigs structure naturally authenticates the </ins> included public name.  This also authenticates any retry signals from the server because the client validates the server certificate against the public name before retrying. <del> 7.5.8. </del> <ins> 11.4.8. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols. <del> 7.6. </del> <ins> 11.5. </ins> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the

Discussion:
This change implements the ESNI -> ECHO design discussed in Singapore. There a couple pending TODOs, particularly around cross-CH HRR binding, but the meat is what's currently being analyzed. cc NAME NAME NAME NAME
This still seems a bit rough, but I think better in the spec than out.