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

Dave Garrett <davemgarrett@gmail.com> Mon, 14 March 2016 19:25 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 104BC12D737 for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:25:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mfGQpM4mrtiK for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 12:25:31 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 A19E412D717 for <tls@ietf.org>; Mon, 14 Mar 2016 12:25:31 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id g3so180699682ywa.3 for <tls@ietf.org>; Mon, 14 Mar 2016 12:25:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=ZB0NlCovF74bTwUaN8+CkMtCY7YF4h/uDLhwSu64EII=; b=bZn1r7M8LjoHM9de8NhBiPNzuJWqBP3c1EPrRh3BWFMwmkJQ9fFLzR37b3WptYvT+2 OXoarhUBtkQf8jMN1Qneq2MQVQNegnlo18BdG/3Iv1uCEd24AK8BPmu2oWP15ce8Pai9 k8mq1rQjDor4k8/m+HglZZj113dnHAE1adLIJ2WHO2z4CVWEuLGKyA/AVWvaV4TG44VF f4yDEBPW+biU91zP6gIq3ZBWaRZrQAMu3u/RZSeQzPxw85HweK2sts3edoEjyDwvv+4Y 26ahq+jE5hXds/DcclBxrM4RIzrle5K8wdRBP1WHY+XiZJzuE9vVs80v7CU3ju9euZfR 5srQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=ZB0NlCovF74bTwUaN8+CkMtCY7YF4h/uDLhwSu64EII=; b=YrxGvjhBhCT1tj8Ns5twrcu3TmHzJR1MoCE7rEXit4/tHJB8Rp6m14DBeo3tYY2hDU e7hV+rC2EfogJ/1O+yrutDMFtvz1Lbz9Rk4qq19Hjm7jHzY26ezpEqrp1uHPSkjmZ+Bb 3Z+eyvHEH3UR+beCqFGfzr3o2QyxteHEheKwaKi2k+K7Li2x88cOanFYGeKTheEw7lY4 J77KKSLHQ5hJa/gAV5hnORJx1sYnK80V3vrj4tuaGy94/R68J26+qQ/7Ug4LO/+i/XmE k+msi9kFBQ0AgFbXcC5tJ5d0dCtSesS2EAR7SodJ05kfZGSmR4gOSdzhIZkYBRYV9K8p Gy/w==
X-Gm-Message-State: AD7BkJJtLdRLY8NGiL3yO6Dgby5o6xPLgmsXSzCJIHeC6hL5LWLIP6IuG8ntnw3X8CdpsA==
X-Received: by with SMTP id 123mr2838976ybe.81.1457983530909; Mon, 14 Mar 2016 12:25:30 -0700 (PDT)
Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. []) by smtp.gmail.com with ESMTPSA id f81sm14925033ywb.38.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 14 Mar 2016 12:25:30 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Mon, 14 Mar 2016 15:25:28 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <56E54B85.4050204@cs.tcd.ie> <CAAF6GDc7mz6u_fu=k4LSqF+5fA-mkTbq0_AZ419WgVruk=BA7Q@mail.gmail.com> <CAH9QtQGti4SdCx2Cd73Moh+0qsx3utvc6trNYCib=BgyLiX=Nw@mail.gmail.com>
In-Reply-To: <CAH9QtQGti4SdCx2Cd73Moh+0qsx3utvc6trNYCib=BgyLiX=Nw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201603141525.29198.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0bbzpkPGxN873TeBZljs1qvMH_4>
Cc: Scott Schmit <i.grok@comcast.net>
Subject: [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:25:41 -0000

(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?