Change:
certificate as authoritative for the public name, this may trigger the retry logic described in handle-server-response or result in a connection failure.  A proxy which is not authoritative for the <del> public name cannot forge a signal to disable ESNI. </del> <ins> public name cannot forge a signal to disable ECHO. </ins> <del> A non-conformant MITM proxy which instead forwards the ESNI </del> <ins> A non-conformant MITM proxy which instead forwards the ECHO </ins> extension, substituting its own KeyShare value, will result in the client-facing server recognizing the key, but failing to decrypt the SNI.  This causes a hard failure.  Clients SHOULD NOT attempt to repair the connection in this case. <del> 7. </del> <ins> 10. </ins> <del> 7.1. </del> <ins> Per RFC8446, TLS ciphersuites define an AEAD and hash algorithm.  In contrast, HPKE defines separate AEAD algorithms and key derivation functions.  The table below lists the mapping between ciphersuites and HPKE identifiers.  TLS_AES_128_CCM_SHA256 and TLS_AES_128_CCM_8_SHA256 are not supported ECHO ciphersuites as they have no HPKE equivalent. 11. 11.1. </ins> In comparison to I-D.kazuho-protected-sni, wherein DNS Resource <del> Records are signed via a server private key, ESNI records have no </del> <ins> Records are signed via a server private key, ECHO records have no </ins> authenticity or provenance information.  This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply clients with <del> fake ESNI records (so that the client encrypts SNI to them) or strip the ESNI record from the response.  However, in the face of an attacker that controls DNS, no SNI encryption scheme can work because the attacker can replace the IP address, thus blocking client </del> <ins> fake ECHO records (so that the client encrypts data to them) or strip the ECHO record from the response.  However, in the face of an attacker that controls DNS, no encryption scheme can work because the attacker can replace the IP address, thus blocking client </ins> connections, or substituting a unique IP address which is 1:1 with the DNS name that was looked up (modulo DNS wildcards).  Thus, <del> allowing the ESNI records in the clear does not make the situation </del> <ins> allowing the ECHO records in the clear does not make the situation </ins> significantly worse. Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but DoH/DPRIVE are also defenses against DNS attacks by attackers on the local network, which is a common case <del> where SNI is desired.  Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit via DoH or DPRIVE mechanisms. </del> <ins> where ClientHello and SNI encryption are desired.  Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit via DoH or DPRIVE mechanisms. </ins> <del> 7.2. </del> <ins> 11.2. </ins> Supporting optional record digests and trial decryption opens oneself up to DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any <del> known ESNI key, in order to force decryption.  Servers that support </del> <ins> known ECHO key, in order to force decryption.  Servers that support </ins> this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. <del> 7.3. ESNI protects only the SNI in transit.  Other ClientHello extensions, such as ALPN, might also reveal privacy-sensitive information to the network.  As such, it might be desirable to encrypt other extensions alongside the SNI.  However, the SNI extension is unique in that non- TLS-terminating servers or load balancers may act on its contents. Thus, using keys specifically for SNI encryption promotes key separation between client-facing servers and endpoints party to TLS connections.  Moreover, the ESNI design described herein does not preclude a mechanism for generic ClientHello extension encryption. </del> <ins> 11.3. </ins> <del> 7.4. ESNI requires encrypted DNS to be an effective privacy protection </del> <ins> ECHO requires encrypted DNS to be an effective privacy protection </ins> mechanism.  However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may

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.