On Tue, Dec 18, 2018 at 02:27:10PM -0600, David Benjamin wrote: > On Tue, Dec 18, 2018 at 3:00 AM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > 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)? > > > > It's possible I didn't word this correctly. If the client did not get ESNI > keys for the server, the client is presumably offering a non-ESNI session, > which has no resumption restrictions. The case we want to avoid is an ESNI > session being resumed at anything other than esni_accept. That's to cut out > the resumption case in {{verify-public-name}}. In particular, if we want to > tolerate partial rollouts where some servers don't support ESNI at all > while others don't at all, this scenario is a concern:
"The server MUST NOT resume any sessions offered by the client that were established without ESNI.". This holds even if client sent a dummy ESNI value. > Without this case (and GREASE---see remark), we could just say servers MUST > NOT resume if they send esni_retry_request. This case the server should at least know if it has ESNI keys or not. > > 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. > > > > This is true. I don't see a clear way around that one, short of taking the > record_digest parameter out and requiring the server do a public-key > trial-decrypt for each unexpired ESNI key. (Perhaps with key mismatch > tolerance, it's no longer necessary for servers to be quite so paranoid > about keeping all their old keys around, but the trial-decrypt still seems > poor.) Especially with asymmetric cryptography, as even the fastest ops are about 100kcyc at least (outside some very rare pieces of laptop hardware). > I think this is still worth doing, especially as it's basically free if you > want to support rollbacks. (Making GREASE work and tolerating ESNI-clueless > servers are very strongly related. GREASE requires that servers > more-or-less ignore ESNI on key mismatch.) You also need to either observe > multiple connections or know something about the server to do this. And then there might be fun with timing attacks. This is whole asymmetric operation, so timing signal should be rather large. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
