Change:
Addresses .
NAME can you please take a look?
Yes, adding a trial decryption is a good thing. Two suggestions: 1) in security section describe privacy attack by tracking the crypto ID. 2) also describe the attack by forcing trial decryption. Maybe add an option to publish ESNI record with NULL checksum as a way to signal acceptance of trial decryption ?
I plan to address this in a PR for . Good suggestion! I'll add that here.
NAME please let me know if the latest text works for you!
NAME NAME can you please take a look?
I think you should say that it has to be somehow externally configured.
Good suggestion! Will fix.
If each client receives a unique ESNI key from a DNS provider, it is possible to link every usage of this key to the same client. It seems feasible that online services, as well as passive observers of the network traffic, can exploit such a practice for user tracking. To enhance the privacy protections of this draft, we should describe these privacy risks in the draft. Furthermore, I recommend a clear restriction on the clients’ caching durations of ESNI keys. For example, clients MUST NOT cache ESNI keys longer than 24 hours and as privacy protection, it is RECOMMENDED to cache ESNI keys only for 10 minutes.
To avoid downgrade attacks (by simply filtering out the key DNS response), clients should cache the fact that there is/was an ESNI key significantly longer, perhaps 14 days. During these 14 days the server can authoritatively report that it no longer has a key, and it can change the key. But the client would actively look for ESNI support before falling back to plain SNI for that server. Bug comment 3 contains a proposal that can implicitly handle the case "client thinks server has ESNI, but doesn't know the current keys or if it has been turned off again server side"
I do not believe this will work. In multi-cdn scenarios, clients will sometimes just get an ESNIKeys record sometimes and no record other times and that's normal
I think noting that this can track you within the same origin is a worthwhile thing to note - it gets added to a whole bucket of things with the same property (e.g. AAAA). As its not really adding anything to that problem I'm not in favor of recommending particular cache ceilings which may or may not really address the issue anyhow..
I observe, that TLS has a tradition in providing upper limits for caching durations. I think this is a good practice as it restricts the harm of an extreme configuration. Furthermore, I see added value in recommending a best practice configuration at least for a specific application type such as browsers because it leads to a description of the trade-offs at hand and facilitates the implementation.
The document already sets the maximum TTL to the lifetime of the SNI key. It also recommends that "servers rotate keys frequently" to reduce the harm from compromised keys. So it seems that short-lived keys are good both for security and privacy. A recommended value would be useful. Otherwise "frequently" could be interpreted as months.

Discussion:
A random 16-octet value to be echoed by the server in the "encrypted_server_name" extension. <del> The true SNI, that is, the ServerNameList that would have been sent in the plaintext "server_name" extension. </del> <ins> The true SNI DNS name, that is, the HostName value that would have been sent in the plaintext "server_name" extension.  (NameType values other than "host_name" are unsupported since SNI extensibility failed SNIExtensibilityFailed). </ins> Zero padding whose length makes the serialized PaddedServerNameList struct have a length equal to

greater.  If not, it MUST abort the connection with a "handshake_failure" alert. <del> If the ClientEncryptedSNI.record_digest value does not match the cryptographic hash of any known ESNIKeys structure, it MUST ignore the extension and proceed with the connection, with the following added behavior: </del> <ins> The ClientEncryptedSNI value is said to match a known ESNIKeys if there exists an ESNIKeys that can be used to successfully decrypt ClientEncryptedSNI.encrypted_sni.  This matching procedure should be done using one of the following two checks: Compare ClientEncryptedSNI.record_digest against cryptographic hashes of known ESNIKeys and choose the one that matches. Use trial decryption of ClientEncryptedSNI.encrypted_sni with known ESNIKeys and choose the one that succeeds. Some uses of ESNI, such as local discovery mode, may omit the ClientEncryptedSNI.record_digest since it can be used as a tracking vector.  In such cases, trial decryption should be used for matching ClientEncryptedSNI to known ESNIKeys.  Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST use the first method. If the ClientEncryptedSNI value does not match any known ESNIKeys structure, it MUST ignore the extension and proceed with the connection, with the following added behavior: </ins> It MUST include the "encrypted_server_name" extension in EncryptedExtensions message with the "response_type" field set to

advertisement (misconfiguration).  Instead, servers can measure occurrences of the "esni_required" alert to detect this case. <del> If the ClientEncryptedSNI.record_digest value does match the cryptographic hash of a known ESNIKeys, the server performs the following checks: </del> <ins> If the ClientEncryptedSNI value does match a known ESNIKeys, the server performs the following checks: </ins> If the ClientEncryptedSNI.key_share group does not match one in the ESNIKeys.keys, it MUST abort the connection with an

7.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 known ESNI key, in order to force decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. 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. 7.4. ESNI requires encrypted DNS to be an effective privacy protection 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 reveal the server identity.  Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess.  It may also include implementation- specific traffic for additional information sources as part of verification. Implementations SHOULD avoid leaking information that may identify the server.  Even when sent over an encrypted transport, such requests may result in indirect exposure of the server's identity, such as indicating a specific CA or service being used.  To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation. 7.5. </ins> I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them. <del> 7.2.1. </del> <ins> 7.5.1. </ins> 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

Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. <del> 7.2.2. </del> <ins> 7.5.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys

by sending different Resource Records containing ESNIRecord and ESNIKeys values with different keys using a short TTL. <del> 7.2.3. </del> <ins> 7.5.3. </ins> This design requires servers to decrypt ClientHello messages with ClientEncryptedSNI extensions carrying valid digests.  Thus, it is

server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.2.4. </del> <ins> 7.5.4. </ins> As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting

ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. <del> 7.2.5. </del> <ins> 7.5.5. </ins> This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.2.6. </del> <ins> 7.5.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.2.7. </del> <ins> 7.5.7. </ins> Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a

client validates the server certificate against the public name before retrying. <del> 7.2.8. </del> <ins> 7.5.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.3. </del> <ins> 7.6. </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