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

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.