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

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.