Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety

Colm MacCárthaigh <colm@allcosts.net> Tue, 29 March 2016 00:44 UTC

Return-Path: <colm@allcosts.net>
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 E1D0312D195 for <tls@ietfa.amsl.com>; Mon, 28 Mar 2016 17:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 9ASqntoY4OXI for <tls@ietfa.amsl.com>; Mon, 28 Mar 2016 17:44:21 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 BDF8912D1BA for <tls@ietf.org>; Mon, 28 Mar 2016 17:44:21 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id g3so639844ywa.3 for <tls@ietf.org>; Mon, 28 Mar 2016 17:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Owa3Ov4FPCCSB6/UcDR3YQNlOLllY2bqke7NKZHmay0=; b=D9l1/hNfVFKLrXSAhMXg87Y6dtb70CWjyu801krbHRHBs6G8IJYzbc5vrEzxzNTgFj d1eCwRBKxC7S6FQiwRYniAbG8w7iyBAqUDcX5MQrYwasNfwBgVN1SAUrYz3nPDjNbtMA meik3xT1HPVptRNT3n/jIlK0ryikqEqlhuiIoZMGveHTqo3rnBqyd9sufONffzDRBJoF 3LKPiS1D5F4NVUld44K6GcfA95udZXsj5H1Ru0EkfL3JLnpkOlJxxNcIaq2HDwYoR4Oe 7wX5jtfChJvG3BcxMRE0Rt7bs1AQtMuFjlijKK+5FFMA/qqO5MnCNQ70aFhWVZCXJMwq wdCA==
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=Owa3Ov4FPCCSB6/UcDR3YQNlOLllY2bqke7NKZHmay0=; b=VYmYqNbx5Cay8NVU8Fi7+1/H9KxIIkARWjMz9Rcwy3yObhxGYZh1eHq91GnmDhgR9V rLBqawuOAbgCkHKV9dWrzWOjUQ+Qe/z1k1x63ZoGUBhLZq8SUM9C6Zh4JXm0JoakbEPY 8Nap6n4/W2hgx6v0VUwiVCWZ9CM78cifolsDNSp0gbK+zpapC9IOVb8VT1rYnJ3n9vu2 It/LF+J2lVnVRb3WjhHqNvnsDJmKMjvtSkyWEz5BVx5X2Saodf4q4tc0qZUtzHEEpcHi ZDdLzKZnRNJsEsY+y75wopZr2wD9nOqhFNqGh2pi0fLcwT0q7as8fYyLOgZGEIlhy0rn PNAw==
X-Gm-Message-State: AD7BkJKPzfEJFL51NCOK20IXGB2lxwsZ8ohshBooheVPF/KXRZSaU42sXw/Tr1Dl2auFVakL9cwuhPfZfgDSnw==
MIME-Version: 1.0
X-Received: by 10.129.155.81 with SMTP id s78mr13961596ywg.24.1459212260592; Mon, 28 Mar 2016 17:44:20 -0700 (PDT)
Received: by 10.129.88.137 with HTTP; Mon, 28 Mar 2016 17:44:20 -0700 (PDT)
In-Reply-To: <CAJ_4DfT28YPvjRSu=OvA6WAtiM4j_8b1GC-X417Knxha6qRawQ@mail.gmail.com>
References: <CAAF6GDeLshxG0o2_a9vPBTMtNHLNf9tynJaPPnAm2ZrAca19iw@mail.gmail.com> <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <BLUPR03MB139612FBF6332AFD3E74AB658C860@BLUPR03MB1396.namprd03.prod.outlook.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> <BLUPR03MB139671E889569CAD5E65E27D8C860@BLUPR03MB1396.namprd03.prod.outlook.com> <CABcZeBOLEbWeZMbNv1He=2h7Oq+GhbZvrLik-Dr=GfsNctTxOQ@mail.gmail.com> <CAJ_4DfT28YPvjRSu=OvA6WAtiM4j_8b1GC-X417Knxha6qRawQ@mail.gmail.com>
Date: Mon, 28 Mar 2016 17:44:20 -0700
Message-ID: <CAAF6GDeQiL8Asps1S82+Ef0eppU6qWh+s1m9xC9t11OQfNN3xg@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
To: Ryan Hamilton <rch@google.com>
Content-Type: multipart/alternative; boundary="94eb2c0b8e7c721352052f2554c5"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MGdJfpD3GAzEF2D8B5M7-wWAoWA>
Cc: "karthik@messengeruser.com" <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety
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, 29 Mar 2016 00:44:24 -0000

On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton <rch@google.com> wrote:

>
> On Mon, Mar 28, 2016 at 3:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> Yes, I believe that this is what people want.
>>
>> On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov <Andrei.Popov@microsoft.com
>> > wrote:
>>
>>> Not sending cookies/authz headers in 0-RTT would solve a part of the
>>> problem, but will browser vendors go for that? I could be wrong, but there
>>> seems to be considerable interest in 0-RTT Token Binding…. so folks must be
>>> planning on sending tokensJ.
>>>
>>
> ​We (Chrome) definitely want this (sending cookies in 0-RTT requests), and
> are doing this today with QUIC (which we can't wait to TLS 1.3-ify). ​
>


Let's leave aside all of the parts about resumption tokens for a minute.
How big  adeal would it be if the early data were like the hints I
outlined? Let's say a request pattern looked something like;

[ replayable_hint data ]
GET /foo/bar/1234 HTTP/1.1
Host: www.example.com
Cookie: somedata
[ application_data ]
GET /foo/bar/1234 HTTP/1.1
Host: www.example.com
Cookie: somedata
...

Obviously this is trivial for clients to generate and send. On the server
side; the server could treat the hint as a signal to start rendering
"/foo/bar/1234". Obviously the request and the headers are more or less
duplicated here; and that uses some bandwidth, but it seems like a pretty
trivial amount. The server can reply with its rendering at the same point
as the existing 0-RTT proposal; it needn't even read the duplicate
request(s) in the application data section.

The benefit is that it makes a lot of idempodence issues go away; if the
application protocol has to reason about the types of data explicitly, we
can be less worried about the potential impact on the many other kinds of
protocol that are layered on top of TLS.

Then next; and slightly crazier - what if the browser were to very
occasionally connect and send only the hint, and the server just had to
deal with it. How big a deal would that be?

-- 
Colm