Draft: draft-ietf-tls-esni

Commentary: Addresses . 
 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 . 
 please let me know if the latest text works for you ! 
 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 does n'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 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 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 .
Paragraph (version A):
The true SNI, that is, the ServerNameList that would have been
sent in the plaintext "server_name" extension.
Paragraph (version B):
Compare ClientEncryptedSNI.record_digest against cryptographic
hashes of known ESNIKeys and choose the one that matches.
Paragraph (version B):
Use trial decryption of ClientEncryptedSNI.encrypted_sni with
known ESNIKeys and choose the one that succeeds.
Paragraph (version B):
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.
Paragraph (version B):
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.