On Tue, Dec 18, 2018 at 03:01:07PM -0600, David Benjamin wrote: > On Tue, Dec 18, 2018 at 1:27 AM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > > > Also connection re-establishment has considerable cost, additional > > TCP roundtrips on top of the extra TLS roundtrips. > > > > Agreed. The other cost is that it cannot be implemented entirely within the > TLS stack, since most TLS stacks do not establish connections. (Though ESNI > already needs caller involvement anyway to get the ESNI keys out of DNS, > and the perf overhead can be fine if you believe it's rare.)
Looks like the missed ESNI penalty with this proposal is 2RTT (1 RTT from new TCP setup, 1 RTT from unusable handshake; Yes I know that both TCP setup and handshake are three-way, but seems like some flights can be merged). > Is the HRR idea being explored in the parallel thread not viable? > > [ That'd be fine by me, one less thing to worry about, but it did > > seem worth exploring at first blush... The suggestion of using it > > as a fallback when there are either no keys in DNS, or they don't > > work also seems like it could be viable. ] > > > > I actually still need to fully digest in that thread. I hadn't even > realized when I sent this how much the two had in common, or I would have > acknowledged it in the mail. Sorry about that. I imagine my email probably > looked odd to you. I'm glad to see we had similar ideas! > > There might be some version that works? We never came up with a formulation > we really liked, and the single-connection version made a lot of things > simpler. Some of the nuisances with doing it together: > > - Sticking two full handshakes on the same connection introduces several > new key changes, which will frustrate QUIC and DTLS. > > - Joining two handshakes at the ServerHello or so frustrates existing > analysis, split mode, and any servers with SNI-dependent cipher parameters. > (Everyone seems to keep asking their hosting providers for silly little > checkboxes to configure TLS parameters.) I had idea of joining at server Finished (with key state left as-is), which would be only 1RTT penalty (unuseable handshake), but this has the same issues with QUIC and DTLS. And trying to make it compatible with dummy ESNI does some rather annoying things to the TLS state machine. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
