Re: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data)

Eric Rescorla <ekr@rtfm.com> Mon, 14 March 2016 19:33 UTC

Return-Path: <ekr@rtfm.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 6C4D312D76B for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:33:38 -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=rtfm-com.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 oQEC0PK6ApOy for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:33:32 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 D1A5F12D756 for <tls@ietf.org>; Mon, 14 Mar 2016 12:33:31 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id g3so180978723ywa.3 for <tls@ietf.org>; Mon, 14 Mar 2016 12:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pWLALy1LHA7l6U/QUVBFm+Ich6qfnlQLoBWXeQg/7+A=; b=Jslxm5V2Mak6Pk7+5H1JjovRxpFOyIBRYeaqIsl336e2L0OBzlK2UQo5Dg/sSts49t A73lbu86UhupbXp4fZtRkPDn0vI2MtGjTm+QB72kNr0zkpa2n3B0T9rjtR8DiDK1No17 FGaePAcK33v10K349Tvpbkz5KIoBCgYak1B0DKqbW6bRvCHgcE0eOrTkUyNWMcmusRIL nFz4FFwWQJVIXRte8RMnSw8LUFxfEcyr9la5Kw1n0usL4AyhDsBKlzBDkEMA3Ta5d1Ay g5Vt5lBNPzbcIvQezGqMZPwhyvPrgbAf1BejCFaPzMGEXHuwsy6gt8TzU5kmDmhoGIlh sICQ==
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:from:date :message-id:subject:to:cc; bh=pWLALy1LHA7l6U/QUVBFm+Ich6qfnlQLoBWXeQg/7+A=; b=efYWEF4TnrbJm7ySt5q50nSm7mdKWfVJgdg0l58oUfpZ5CWddZxWvwJmLwBuGn+LYI HL2DJj9ttY1MyxyslktyUkqN5kj7HXaMLMNnyun+1IdCcVRl327EXCZPRwUOWySseVWp T8i8dm9fZ9T3dyHQsIxM/wGnAHgn0XReBmojo7aRQfKBBKyzISWSTN4L9lUbza1+1kGk +LMEDrKesFQ7so2Tjqs5cvRkRf0Dx7hccvPzSQd1TjVmxixp3M+blsUM/EpHALDB2dcB dmTzui/O79x/l3uBNoFjMqjdxPwyksaU0joTgkp+EbmaAduMti0cfPLq8JBvzxxpO7xZ MVpQ==
X-Gm-Message-State: AD7BkJIf7JMiASLGenLTKoeu3ScC8VAnFPFNKIWHLoyAid8PEwPB+iFtyFlKa4l8LgTAfBuwgXPtTKPiEDdbTg==
X-Received: by 10.129.46.87 with SMTP id u84mr12908403ywu.129.1457984010964; Mon, 14 Mar 2016 12:33:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 12:32:51 -0700 (PDT)
In-Reply-To: <201603141525.29198.davemgarrett@gmail.com>
References: <56E54B85.4050204@cs.tcd.ie> <CAAF6GDc7mz6u_fu=k4LSqF+5fA-mkTbq0_AZ419WgVruk=BA7Q@mail.gmail.com> <CAH9QtQGti4SdCx2Cd73Moh+0qsx3utvc6trNYCib=BgyLiX=Nw@mail.gmail.com> <201603141525.29198.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Mar 2016 12:32:51 -0700
Message-ID: <CABcZeBP0SNp_5ahB66iS4P_6z8Zsm0MxZ5sR3kzJHnjXBAE9VQ@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary=001a114140ba1014aa052e075bcd
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mBBRfwMReZaf8T5i8Q6ALoLenZo>
Cc: Scott Schmit <i.grok@comcast.net>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe 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: Mon, 14 Mar 2016 19:33:38 -0000

On Mon, Mar 14, 2016 at 12:25 PM, Dave Garrett <davemgarrett@gmail.com>;
wrote:

> (This thread has gotten long and winding, so I'm replying to these two
> portions bellow under a new subject. Reply after quotations.)
>
> On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote:
> > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh <colm@allcosts.net>;
> wrote:
> > > On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <waywardgeek@google.com>;
> wrote:
> > >> As we all know, what matters most in security is the default mode.  I
> am
> > >> suggesting making the default 0-RTT resumption mode stateful, with a
> > >> documented session-ID (and let's bring back the timestamp, too, since
> we'll
> > >> need it).
> > >
> > > Having state would make things much more robust; but rather than the
> state
> > > being around the channel itself (the TLS session), would it be more
> robust,
> > > and more flexible, for the state to be around the action? like some
> kind of
> > > hint cookie.
> >
> > It looks like server-side state is required to prevent replay.  I don't
> > think any kind of token, cookie, or server-config can fix this.
> >
> > > One of the problems with session resumption is that in order to be
> replay
> > > safe; the sequence number has to restart where it left off. That
> requires
> > > some kind of transactional store, and if you're doing all of this for
> > > latency, you may end up eating all of the wins there.
> >
> > The new tickets can in theory end the debate over session caching vs
> > session tickets, since they can be used for database lookups or contain
> an
> > encrypted session state.  However, the spec does not document how to do
> > session caching with tickets securely, which looks tricky.  In reality,
> if
> > I were trying to build a speed and security sensitive site using TLS 1.3
> > stateful 0-RTT resumption, I would probably do something like this:
> >
> > During the initial 1-RTT handshake:
> > - create a ticket containing only the session ID, resumption count, and a
> > session decryption key
> > - encrypt the session cache entry with the session encryption key stored
> in
> > the ticket
> > - encrypt the ticket with a semi-static ticket encryption key, which I
> > would rotate every few weeks
> > - send the ticket to the client, which is after encryption is enabled on
> > the connection
> >
> > During a 0-RTT resume handshake:
> > - check for a cache hit, and drop to 1-RTT if not found
> > - decrypt the ticket with ticket the semi-static ticket decryption key
> > - decrypt the cached session state with the session key from the ticket
> > - compare the resumption counts in the session state and ticket, and fall
> > back to 1-RTT if they do not match
> > - increment the resumption count
> > - create a new session ticket with a new session encryption key and the
> > updated resumption count
> > - encrypt the session cache entry with the new session encryption key
> > - send the client the new ticket
>
> On Monday, March 14, 2016 08:10:32 am Nikos Mavrogiannopoulos wrote:
> > It is important to see how protocols are perceived. For many people TLS
> > 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an
> > attack against TLS 1.3 with rtt, will be perceived as an attack against
> > TLS 1.3 protocol. Even if the published attack against TLS 1.3 with
> > 0rtt was an expected one (i.e., replay of data), if the attack impact
> > is high, that may not be sufficient to stop the avalanche of bad
> > publicity. In turn that will lead several people losing confidence to
> > TLS 1.3 as a protocol, even TLS and the IETF process overall.
> >
> > My suggestion, if you need 0rtt, publish it as a different document,
> > don't mix it with TLS 1.3. The security requirements from TLS are
> > vastly different from the security requirements of a 0rtt protocol.
>
> Previous discussion seemed to land on the conclusion that semi-static DH
> 0RTT should be defined in a separate document, and after this discussion
> I'm beginning to agree that all stateless 0RTT should be defined as a
> separate companion document to the main TLS 1.3 specification. We can
> likely agree on defining a stateful 0RTT PSK resumption system which is
> sufficiently safe and mistake-resistant, and we could restrict the official
> TLS 1.3 spec to only specify that, whilst referencing the other document as
> a more experimental feature that could be available to certain applications
> (possibly a non-standards-track document). HTTPS could then, itself, have a
> separate document laying out the necessary practices to do stateless 0RTT
> safely, and other applications should be warned that without a similar such
> document, things are very risky.
>
> Is this in the ballpark of what the WG could agree on to help mitigate
> some of the problems here?
>

As far as I can tell, there's no protocol difference between "stateful" and
"stateless" resumption.
You use the same techniques (a replay cache) and the question is merely
whether the server
actually maintains one.

-Ekr



>
> Dave
>