On Mon, Dec 17, 2018 at 05:17:37PM -0600, David Benjamin wrote: > Hi folks, > > We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd like > the group's thoughts on. The goal is to make ESNI more robust and eliminate > a bunch of deployment risks. The PRs are linked below: > > https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > > The second recommends clients to send GREASE ESNI extensions when they do > not have cached ESNIKeys available. This better meets the "Do not stick > out" goal. The server behavior in the first PR gives us this for free.
It seems to me that if server thinks it has ESNI enabled, but the client does not get ESNI keys for it, then all handshakes fall back to full handshake and session resumption will not work (as the server is required to reject the resumption)? Also, randomly generating the ESNI key handle does stick out, as normally the ESNI key is releatively static (DNS caching!) across whole group of domains and servers. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
