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

Ryan Hamilton <rch@google.com> Tue, 15 March 2016 00:44 UTC

Return-Path: <rch@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B550912D523 for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 17:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkRnRYI0r8Fq for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 17:44:21 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8FF12D501 for <tls@ietf.org>; Mon, 14 Mar 2016 17:44:20 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id l68so130970775wml.0 for <tls@ietf.org>; Mon, 14 Mar 2016 17:44:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5ELOFPuOsBlUA2ay+FCu8W42dCdZeVcDnEV+H74eUk0=; b=bVJqqxYV18qLXGEGSuF0EkOrnk3J9CTMLdcB6m0aranZnDN1Ufhnk52EMawyIM5Qvx +/q4SzX15OdvdDsWg7irdD+qch0L7Ugo0geLRn6haZ4DYJnrsYyXF2LjJKDuPFSJ73mV hNIOaz7/PgCvOeHtKJTgSzuDZpyczwTsPZ/OPhKnLvDSxiNEQ7K34Vc/j2EXThAWSFwj 69OwE1ZpdcCIIbFqoDPSBaxFuxgEquAj/QY/Kt4rpJ/bcMRLjeRt7y5WidIGdpKhviqf WaezLA1Qdgo86xyaHMINwS8XGxvn+zVTpB4L4AWeWYm8pNa3Q8U7H0PERZYk4itHOihi 4YkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5ELOFPuOsBlUA2ay+FCu8W42dCdZeVcDnEV+H74eUk0=; b=WAinXVHtJaAqcmS1C8T2YwTqEajZ6MS0L1DlwjvS4MZafyzRrCcjG1onURxgvyKOXZ /L0wTNBaXnPW/MYhZl+7sJj2pKxLnjE19L/SG2XwRnCF0m7AatTsBABeR2rzyPdV8fRB Tu196K08npDdZm7kgGSHYupJOOgV7W4uomPVWd8HqU4PryTs7E73beuJrIA+zCbTZsaU ZHQcHpIFouJAM9tFpkvp2ZX73Y9jd49ftsUbdzfEi9pfTD4Y+JtYzSWsld2TOl/gH57l LrPL8eUQX5kvylfFex9vPSVvJLln1frk2f4P7ZCTqigkrZsW9OXY55s2lsr+txrhECo6 NLYg==
X-Gm-Message-State: AD7BkJIl4IcQQk3pdR0Bi2BJWMXP5CL+zZF+6lvje+P2C5Newj/fhQI7z8/r3ajvCeYbGTNr7JUa+rNTRr848sLp
MIME-Version: 1.0
X-Received: by 10.194.81.103 with SMTP id z7mr26544703wjx.25.1458002659322; Mon, 14 Mar 2016 17:44:19 -0700 (PDT)
Received: by 10.28.30.75 with HTTP; Mon, 14 Mar 2016 17:44:19 -0700 (PDT)
In-Reply-To: <CAAF6GDe_Hk8DPm3_vVnmgM56NkoN8SDSA4+c_VdmQwNxfxbwtQ@mail.gmail.com>
References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <CABcZeBPxMZEuG4KehxyhNafeQ4-HO9O-9ORn+BiQP0n3LJA_xw@mail.gmail.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> <CAH8yC8nwyTf7N1y=NqmkVoY1tW6Kh4weFFLEFn6w3vLwoEMRSA@mail.gmail.com> <CAJ_4DfR1dhX7KHB2MQF9YKxrnKGmY9YvhqOyr=6+FbsTJFFqFA@mail.gmail.com> <CAAF6GDe_Hk8DPm3_vVnmgM56NkoN8SDSA4+c_VdmQwNxfxbwtQ@mail.gmail.com>
Date: Mon, 14 Mar 2016 17:44:19 -0700
Message-ID: <CAJ_4DfQ5FD0ajn0sKudCQTQZZeUdVnjxu54Sypw-o62p==7VGw@mail.gmail.com>
From: Ryan Hamilton <rch@google.com>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Content-Type: multipart/alternative; boundary=047d7bf0d1d697726a052e0bb2ae
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ygi4qXebgl1HSjQIJ66-lplzBpg>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Limiting replay time frame of 0-RTT data
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2016 00:44:23 -0000

​On Mon, Mar 14, 2016 at 2:04 PM, Colm MacCárthaigh <colm@allcosts.net>;
wrote:

> On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton <rch@google.com>; wrote:
>>
>> On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton <noloader@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.

I confess, I am not an expert in this area and am relaying conversations
I've had in the past. I hope I'm not making a mess of them.


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

​We have other data (which I don't think we've published, at least not in
that post) which shows that this improvement is definitely perceptible to
users. The improvements in response time are correlated with other metrics
showing that users notice the improvements and behave accordingly. When we
have screwed up 0-RTT (whoops, bug!) these metrics declined. Then when we
fixed it again, they recovered. ​I could go on for a long time about the
various A/B experiments we have run, but suffice to say we're very
confident that 0-RTT is a significant win.

Keep in mind that 3% for search represents *all* page views, not just those
that are the first on a connection, for which 0-RTT can be used. Many of
those page views are on long lived questions for which 0-RTT did not come
into plays, so the effect of 0-RTT on the page views which it sped up is
amortized across all views.

Hope that helps,

Ryan