Re: [TLS] Limiting replay time frame of 0-RTT data

[Colm MacCárthaigh <[e-mail]>]

On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton <[e-mail]> wrote:
>
> On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton <[e-mail]>
> 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