On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton <r...@google.com> wrote: > > On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton <noloa...@gmail.com> > wrote: > >> 0-RTT seems to be a solution looking for a problem. >> > > Google has been using 0-RTT as part of the QUIC transport for quite a > while now. In April of last year, we posted about the performance > benefits we're seeing from QUIC > <http://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html>. > Among other things, that post said: > > Even on a well-optimized site like Google Search, where connections are > often pre-established, we still see a 3% improvement in mean page load time > with QUIC. > > > From the browser side of things, 0-RTT is a solution to a very real > problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT > resumption) and converting QUIC to use the TLS 1.3 handshake as a result. >
Are you sacrificing forward secrecy in this case? For a concrete example: suppose $oppressive_government is collecting all traffic as a routine matter of course, and then later a remote-ex, memory-disclosure, or decrypt-oracle (like the recent DROWN) came along on the server side: could it be used to decrypt all of $worthy_dissident's requests? how long for, how do you manage that trade-off? On the "3% speed up" - we're not going to see that for TLS 1.3 though - right? there's still the TCP handshake to perform; or is some kind of custom TCP in the works? (does TCPCT work on the client side?). Do you have any human perception data; to people even notice the 3% at this point? (loading google seems remarkably fast!). There's a very strong temptation to bias for what's easy to measure here. -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
