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

Bill Cox <> Mon, 14 March 2016 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E7FA12DC67 for <>; Mon, 14 Mar 2016 11:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Le5LsEbqDL2g for <>; Mon, 14 Mar 2016 11:38:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AC9612DB71 for <>; Mon, 14 Mar 2016 11:38:28 -0700 (PDT)
Received: by with SMTP id ig19so68808755igb.1 for <>; Mon, 14 Mar 2016 11:38:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KwAf6jvh0oM8f1b8UAEHfB5dPKmjWWDmwNAeetKJ+nY=; b=B0cO5SleAN3wrYnNbJiEAe4uq13zrwd9ivZCiadnWfzdMAXe98F8/PrXaTG5uXK2eI xZFX1nYXRj8zk6S8KfHu3DlLP4OaDSCHKiIqQnY8otg3KwOyTPwO5CpmuBHV8DotKU8j 8YYs4kimBFfYbCzQW85X/z52wiLh7ayZwUAtKsVVPOBY0eFU8Ov6T0YlaF9Y3CDAhQIZ qJcesjFz3zXp+b1ZQSnDTz5BefX4Uk8uJqt3AaoWjqD5u8Zn0u4ahVcSpdzORge3Bv1l 20PFSxuuViWxLxZ6pq54Jz47Ju0uZWQM5iPfU4CzU7CymtvSnm2a7DKX2/4XKgI0kSr4 SSUg==
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:date :message-id:subject:from:to:cc; bh=KwAf6jvh0oM8f1b8UAEHfB5dPKmjWWDmwNAeetKJ+nY=; b=CtyjKZ3WG65wuZRgxdh9JhTSGoLW6dzi7TKN98mbpwHQR4DyHeEeObdqhb2s2MrMe8 qAYIKJfejKPfOwZP1NAR/9rbyXtRKpPQmG5sVLGNNERCWyfwmPJH1yUJ3xM+ItzfusFq efSNV7dD0Ys1NV9YG99B2ELGb2+cW+2ptqf9m6crvqBy5JsnL2kE7gQsVCcb8a5Etpz3 eKrARdkrGRd0IpDJOQYHUFQK/F16lWsLor8juGRI3XlnoHdpG3wN3Jw7UnFi9SrtM+0N tmhPe/SLp7RuzKRqWq0usCCezLzhkBa17dY7Gs46uiWb4SHePnIhmzlha7z4vowaP21m eh/w==
X-Gm-Message-State: AD7BkJJedFdWWmvEmF0RTsvHspCTJNXOvPbCPGfSNsMNcQ7Nt/+oQ1S9ciYSoUYfTrsF0ksbOAQk0NUews1zdSQ7
MIME-Version: 1.0
X-Received: by with SMTP id j7mr19128375igu.40.1457980707487; Mon, 14 Mar 2016 11:38:27 -0700 (PDT)
Received: by with HTTP; Mon, 14 Mar 2016 11:38:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Mon, 14 Mar 2016 11:38:27 -0700
Message-ID: <>
From: Bill Cox <>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Content-Type: multipart/alternative; boundary=047d7b3a93c629610d052e0696ef
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: Mon, 14 Mar 2016 18:38:32 -0000

On Mon, Mar 14, 2016 at 9:10 AM, Colm MacCárthaigh <>

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

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.