(Hit send too early) On Tue, Dec 18, 2018 at 3:32 PM David Benjamin <david...@chromium.org> wrote:
> On Tue, Dec 18, 2018 at 3:06 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > >> 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. >> > Oops, yes, that was a typo. It should have said: The server MUST NOT resume any sessions offered by the client that were established with ESNI. I'll fix that. Thanks for catching that! > > 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. >> > > Sorry, that was really confusing. By "this" I meant GREASE, not trial > decryption schemes. :-) >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
