On Mon, Mar 14, 2016 at 5:44 PM, Ryan Hamilton <r...@google.com> wrote:
> On Mon, Mar 14, 2016 at 2:04 PM, Colm MacCárthaigh <c...@allcosts.net> > wrote: > >> 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? >> > > My understanding is that QUIC's current 0-RTT scheme provides effectively > the same protection as TLS with perfect forward security, at least assuming > that session resumption is enabled. This is because, as I understand it, > even with PFS connections, and attacker who is able to compromise the > server and access the session resumption key can do bad things. In our QUIC > deployments, we limit the lifetime of the QUIC 0-RTT static secret to > roughly the lifetime of our session resumption key. > This is, I think, more or less true. In general, against complete compromise of the server at time X, the security is limited to whatever long-term key was used to protect that data. Generally, this means that tickets and static DHE are comparable against server key compromise [0], so for this kind of attack tickets and semi-static DH are roughly comparable (indeed, you could imagine having the configuration ID be an encryption of the semi-static DH key under the ticket key making them strictly comparable) [1]. The situation is obviously more complicated with attacks where you don't have control of the server (e.g., oracle-type stuff) and I suspect depends on the details of the attack. -Ekr [0] As AGL points out, client key compromise is somewhat different. [1] If you decide to instead store keying material on the server rather than use tickets, then TLS 1.3 PSK 0-RTT actually has somewhat better properties because you can negotiate a new key with each connection and establish a new "ticket", so the result is that compromise of the server is a future secrecy threat but not a threat to past connections.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
