Change:
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

Discussion:
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.