Re: [TLS] Forward secrecy with resumption, and 0-RTT security

Eric Rescorla <> Sun, 06 December 2015 15:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9B3381A9023 for <>; Sun, 6 Dec 2015 07:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQpr1fb_1UT8 for <>; Sun, 6 Dec 2015 07:13:16 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA3441A9004 for <>; Sun, 6 Dec 2015 07:13:15 -0800 (PST)
Received: by ykdr82 with SMTP id r82so170195802ykd.3 for <>; Sun, 06 Dec 2015 07:13:15 -0800 (PST)
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:content-type; bh=o5s0YtFseTHYOBcIr28TZq17udx6uAmlQAxwoKObwX0=; b=2DBzi54JoZtkJCnUR0puvIdLi0BLWZcxgYsRNNdtqKAjedYM4rD9d26W7DFclZJAxc ot3/61skXcRHBjTQBYY3ep/DVkFaghcfZ3+El0yfZCvvq8kca0HjOE5Kh4Hhy/y7cXmJ 64jgqY0CAtWafPpO53711nJRrG7TxNJBMB/jxX5IZ/cy9gkkz5v11sxxPjKY56HTZdl2 OJDN8cIZVFciEDCpsPevvT3Lrge6ZiE89vzGyRDRVnoXXUtXGNpoUerp1ezPYtlkvtnM id/7/PQR+XjmucfMCAXGovgbDLZRWBG4YhGtZqD5Z3wPOhuMYDEZdXcziq8XOwwQwCG7 0D4A==
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:content-type; bh=o5s0YtFseTHYOBcIr28TZq17udx6uAmlQAxwoKObwX0=; b=aU7JnmuEFCso+d2sbxG+CwGZagFTd7y4FDJbxLpeoagVeH1ymNyz43iEkzKV4U4wr3 vGc0JrI/Hbgr5unJHiBuyCTiNpnrji08OVn+O/jETl1YzQ430whUiVulbaFQdRR4QpzR 0XOgc/MxquM+7Kt+V3KaKLNMStpmT+QLVF7Ncd6CRMzodFlppr7SvYy5NA3XtSArYYBX ChEYJ3tOC4s39u3rzrVqiOPAZdH3/TWFu3I+oocf/9dfP6Dm5z2TPNSs1eBC5dBDNclz fVHdU4ySALJ5EQe89QkKSTf0Xvxno3WsPpqcP38ZueXj+dCDjMORYSCBcrLi526/A/Ix w0MQ==
X-Gm-Message-State: ALoCoQlhCZDvWoWld+D6fqN9LG/jH+JWAyoA9iDMI9aMICa2PsEh1/eYj8hacD4FWrhYcLnO8BwS
X-Received: by with SMTP id u81mr18275019ywu.129.1449414795121; Sun, 06 Dec 2015 07:13:15 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 6 Dec 2015 07:12:35 -0800 (PST)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Sun, 6 Dec 2015 07:12:35 -0800
Message-ID: <>
To: Bill Cox <>
Content-Type: multipart/alternative; boundary=001a11409380ff049205263c2d0b
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security
X-Mailman-Version: 2.1.15
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: Sun, 06 Dec 2015 15:13:17 -0000

On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox <> wrote:

> AFAIK, there has never been a session resumed with forward secrecy.  Is
> this correct?

Yes, session resumption does not have PFS. Though note that with 1.3 that
no longer be true, because you can do PSK-DHE.

> In the past, there were two cases: resumption using session IDs, and
> resumption with session tickets.  Using session IDs loses forward secrecy,
> because the server always has session keys in a session cache, which could
> be used to decrypt the prior sessions.  Using tickets did not work either,
> because the server always kept a ticket decryption key which could be used
> to decrypt all resumed sessions since the key was last rotated.

Well, the server could in principle delete the keys from the session cache
and (at more
cost) the decryption key But yes.

> To have forward secrecy under the strict definition using the new PSK
> scheme, we need to use what the new name implies: pre _shared_ keys.  The
> new name implies that the server remembers a unique shared key for the
> connection, which is server-side state per resumable connection.  If we
> only store the PSK in the ticket, and go stateless on the server, then the
> server-side ticket decryption key again defeats strict forward secrecy.
> With a remembered server-side pre-shared secret, we can have a 0-RTT resume
> with strict forward secrecy.  Is this already implied in the spec?  If so,
> the spec could be improved, by stating this explicitly.  However, the
> current statement that 0-RTT does not provide forward secrecy seems to be
> wrong in the case that we resume a 0-RTT connections with a
> server-remembered PSK.
> To have strict forward secrecy, given that the server already has to have
> server-side state (the pre-shared key), I find the old session ID scheme
> more palatable than the new tickets.  The main point of session tickets was
> to eliminate the server-side session cache, wasn't it?

The current ticket scheme is compatible with either a server-side database
*or* having self-contained
tickets which are encrypted with a server-side key. (This was also true for
tickets, it's just that
you didn't bother with tickets if that is what you wanted). If you want a
database, you just use
an identifier as the key name. The point is to have a mechanism which
accomodates either

I think the current spec does not describe well enough how to implement
> secure 0-RTT infrastructure.  Instead, it seems to recommend against using
> 0-RTT, with a pretty dire warning about the insecurity of 0-RTT.

Well, the primary purpose of this warning isn't to warn about PFS. It's
really to warn
about the replay issue, which is unique to 0-RTT and which can't really be
by proper implementation. The issue isn't that it's not possible to have
if you're willing to store server side state, but rather how you respond to
server-side state
loss. Moreover, the problems exist whether or not you use certificate-based
client authentication.

I haven't thought this through in as much detail as I've thought through the
non-PSK 0-RTT case, but I don't believe that PSK-resumption solves the
problems with replay. The basic issue is the same: what happens when
a server gets a connection attached to state which it doesn't have. So,
what the attacker would do duplicate the ClientHello + PSK and send one
copy to the true datacenter and one to another datacenter that doesn't have
state. The right datacenter will process the 0-RTT handshake and the
wrong one will reject it, causing the client to fall back to 1-RTT and
the request. So, you still get replay.