Change:
case, it does not make any changes to the TLS messages, but just blindly forwards them. <del> If the ClientHello is the result of a HelloRetryRequest, servers MUST abort the connection with an "illegal_parameter" alert if any of the ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, ClientEncryptedSNI.record_digest, or decrypted ClientESNIInner values from the second ClientHello do not match that of the first ClientHello. 5.3. A server operating in Shared Mode uses PaddedServerNameList.sni as if it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key.  Moreover, the server MUST include the "encrypted_server_name" extension in EncryptedExtensions with the "response_type" field set to "esni_accept" and the "nonce" field set to the decrypted PaddedServerNameList.nonce value from the client "encrypted_server_name" extension. </del> If the server sends a NewSessionTicket message, the corresponding <del> ESNI PSK MUST be ignored by all other servers in the deployment when not negotiating ESNI, including servers which do not implement this </del> <ins> ECHO PSK MUST be ignored by all other servers in the deployment when not negotiating ECHO, including servers which do not implement this </ins> specification. <del> This restriction provides robustness for rollbacks (see misconfiguration). 5.4. In Split Mode, the backend server must know PaddedServerNameList.nonce to echo it back in EncryptedExtensions and complete the handshake.  communicating-sni describes one mechanism for sending both PaddedServerNameList.sni and ClientESNIInner.nonce to the backend server.  Thus, backend servers function the same as servers operating in Shared Mode. As in Shared Mode, if the backend server sends a NewSessionTicket message, the corresponding ESNI PSK MUST be ignored by other servers in the deployment when not negotiating ESNI, including servers which do not implement this specification. 6. </del> <ins> 9. </ins> <del> Unlike most TLS extensions, placing the SNI value in an ESNI </del> <ins> Unlike most TLS extensions, placing the SNI value in an ECHO </ins> extension is not interoperable with existing servers, which expect the value in the existing cleartext extension.  Thus server operators <del> SHOULD ensure servers understand a given set of ESNI keys before </del> <ins> SHOULD ensure servers understand a given set of ECHO keys before </ins> advertising them.  Additionally, servers SHOULD retain support for <del> any previously-advertised keys for the duration of their validity. </del> <ins> any previously-advertised keys for the duration of their validity </ins> However, in more complex deployment scenarios, this may be difficult to fully guarantee.  Thus this protocol was designed to be robust in <del> case of inconsistencies between systems that advertise ESNI keys and </del> <ins> case of inconsistencies between systems that advertise ECHO keys and </ins> servers, at the cost of extra round-trips due to a retry.  Two specific scenarios are detailed below. <del> 6.1. </del> <ins> 9.1. </ins> <del> It is possible for ESNI advertisements and servers to become </del> <ins> It is possible for ECHO advertisements and servers to become </ins> inconsistent.  This may occur, for instance, from DNS misconfiguration, caching issues, or an incomplete rollout in a multi-server deployment.  This may also occur if a server loses its <del> ESNI keys, or if a deployment of ESNI must be rolled back on the </del> <ins> ECHO keys, or if a deployment of ECHO must be rolled back on the </ins> server. The retry mechanism repairs inconsistencies, provided the server is authoritative for the public name.  If server and advertised keys <del> mismatch, the server will respond with esni_retry_requested.  If the </del> <ins> mismatch, the server will respond with echo_retry_requested.  If the </ins> server does not understand the "encrypted_server_name" extension at all, it will ignore it as required by RFC8446; Section 4.1.2. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in handle-server-response. <del> Unless ESNI is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to cleartext SNI, as this allows a network attacker to disclose the SNI. It MAY attempt to use another server from the DNS results, if one is </del> <ins> Unless ECHO is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using unencrypted ClientHellos, as this allows a network attacker to disclose the contents of this ClientHello, including the SNI.  It MAY attempt to use another server from the DNS results, if one is </ins> provided. <del> 6.2. </del> <ins> Client-facing servers with non-uniform cryptographic configurations across backend origin servers segment the ECHO anonymity set based on these configurations.  For example, if a client-facing server hosts k backend origin servers, and exactly one of those backend origin servers supports a different set of cryptographic algorithms than the other (k - 1) servers, it may be possible to identify this single server based on the contents of the ServerHello as this message is not encrypted. 9.2. </ins> A more serious problem is MITM proxies which do not support this extension.  RFC8446; Section 9.3 requires that such proxies remove

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.