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. > > > 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
