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

Eric Rescorla <ekr@rtfm.com> Sun, 06 December 2015 15:13 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3381A9023 for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 07:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQpr1fb_1UT8 for <tls@ietfa.amsl.com>; Sun, 6 Dec 2015 07:13:16 -0800 (PST)
Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 CA3441A9004 for <TLS@ietf.org>; Sun, 6 Dec 2015 07:13:15 -0800 (PST)
Received: by ykdr82 with SMTP id r82so170195802ykd.3 for <TLS@ietf.org>; Sun, 06 Dec 2015 07:13:15 -0800 (PST)
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: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; d=1e100.net; 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 10.129.46.84 with SMTP id u81mr18275019ywu.129.1449414795121; Sun, 06 Dec 2015 07:13:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.197 with HTTP; Sun, 6 Dec 2015 07:12:35 -0800 (PST)
In-Reply-To: <CAH9QtQEMcVkZAwOS5xCWFCw0uBvQd+Q+Wsj7fXtm3_p6XHk_pA@mail.gmail.com>
References: <CAH9QtQEMcVkZAwOS5xCWFCw0uBvQd+Q+Wsj7fXtm3_p6XHk_pA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 6 Dec 2015 07:12:35 -0800
Message-ID: <CABcZeBPLtB3YZsEpm9+xhm9p2H7q__68JS8Vx=Lw1Ae-5e94Kg@mail.gmail.com>
To: Bill Cox <waywardgeek@google.com>
Content-Type: multipart/alternative; boundary=001a11409380ff049205263c2d0b
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/85zorX25DSnrytG1vbcgitzwWHI>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Forward secrecy with resumption, and 0-RTT security
X-BeenThere: tls@ietf.org
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." <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: Sun, 06 Dec 2015 15:13:17 -0000

On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox <waywardgeek@google.com> 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
will
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
design.


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
fixed
by proper implementation. The issue isn't that it's not possible to have
anti-replay
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
retransmit
the request. So, you still get replay.

-Ekr