Re: [TLS] analysis of wider impact of TLS1.3 replayabe data

Eric Rescorla <> Tue, 15 March 2016 01:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D35C12D6D6 for <>; Mon, 14 Mar 2016 18:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IS_7hkYHVvCT for <>; Mon, 14 Mar 2016 18:46:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DA8F12D53E for <>; Mon, 14 Mar 2016 18:46:52 -0700 (PDT)
Received: by with SMTP id d65so3771008ywb.0 for <>; Mon, 14 Mar 2016 18:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZrrnLkjaIJMLgbRI+tVjW5wVe1Vwk70C4yIIedwDotc=; b=vbJrhrSa2zpSiFfZiACm1e5mR8X3ETI1YGmpPt3o7SIr6d8zXOfjCY2T6GHVB+/S7y KAWz2gmqex4UQDj0G8STiKX5ovfqlimhZetq3K6NfpcYqInkjsZmcH/MTzfKsKUMi/fB 9+FrJn6z6vN1srWnhUuHQMgtE2oLWNzRxrGf82Kh60r55FTsmFI0oZNUeEMCavByL2St 5aEgbHz0RT+b9mrNWNCWFANwdP8LITQJeUN6uepS8cQTh1qH81YzTTajtZri607Psbnt tnN6+HIvqz7jZi6OaJzOJQ3MTwIJNHbHcsX5pJa6yi6daCQPVNKkeTKwRCQGtjCgL/tj LbuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZrrnLkjaIJMLgbRI+tVjW5wVe1Vwk70C4yIIedwDotc=; b=JbpNEJzjhMzoM4VWSREvagXAnKRMwl6AdSAqk2KLrM+WoL9y0t75K0iL5EC15No894 A/5H56TbKjEb0bJGhP3O7LFvxyn4nSlVsq49rd+XIBokj5ko9deOQDfNJRGTVoFnn/ts JoeiXRpz5WZw7SrnfLWQeTkzdHHKAkkt/2NckfG8TxBbvwSywPhJZyd76y+iL6p0V6US W/Svzx+34OtzRhTVFHbkRpoLyEO4cQV5Mx4C2qbSkbEOEpgWP2qSyp/4lscY52ruH/UN 91iZDCwh9Tf2x4Yb0QeVegPzzPK5Er8rRINbome4vJN1d3aIleHZOHQmrLh+8GvDKWdR fF7g==
X-Gm-Message-State: AD7BkJLXI+0OCJwYY15sF/o7dSKSnzgpqxrAZ2XwhV2iH/0hSMhDuMYOzTO3QaiH3isFI68Unv1Z3TAw8T+E6Q==
X-Received: by with SMTP id d19mr13380796ywb.115.1458006411645; Mon, 14 Mar 2016 18:46:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 14 Mar 2016 18:46:11 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 14 Mar 2016 18:46:11 -0700
Message-ID: <>
To: Bill Cox <>
Content-Type: multipart/alternative; boundary=001a114dad0e3f480a052e0c92f3
Archived-At: <>
Cc: Scott Schmit <>, "" <>
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Mar 2016 01:47:03 -0000

On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox <> wrote:

> On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh <>
> wrote:
>> On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <> 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
> I assume that it is legal to send a new ticket on a 0-RTT PSK resume, but
> it is not clear to me from the drawings in the spec.  It is not shown as an
> option.  This is required for secure stateful 0-RTT resumption.

Yes, this is legal. I'll see if I can clarify this in the text.


I think this scheme minimizes data sent over the wire (to reduce latency)
> and provides improved PFS vs using a non-encrypted session cache.  Since
> tickets are sent after encryption has been enabled, leaking the semi-static
> ticket encryption key does not enable an eavesdropper to decrypt past
> sessions, as was the case in TLS 1.2.  If the server is compromised, this
> scheme protects the session cache from being decrypted, so PFS is
> preserved, unlike the case with either TLS 1.2 session caches with no
> encryption or TLS 1.2 tickets with semi-static ticket keys.  Leaking either
> the session cache or ticket encryption key would allow prior TLS 1.2
> sessions to be decypted.
> Bill