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

Eric Rescorla <ekr@rtfm.com> Tue, 15 March 2016 01:47 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35C12D6D6 for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 18:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 IS_7hkYHVvCT for <tls@ietfa.amsl.com>; Mon, 14 Mar 2016 18:46:58 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 5DA8F12D53E for <tls@ietf.org>; Mon, 14 Mar 2016 18:46:52 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id d65so3771008ywb.0 for <tls@ietf.org>; Mon, 14 Mar 2016 18:46:52 -0700 (PDT)
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; 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; d=1e100.net; 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 10.129.79.19 with SMTP id d19mr13380796ywb.115.1458006411645; Mon, 14 Mar 2016 18:46:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 18:46:11 -0700 (PDT)
In-Reply-To: <CAH9QtQGti4SdCx2Cd73Moh+0qsx3utvc6trNYCib=BgyLiX=Nw@mail.gmail.com>
References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <CAH9QtQFAJkq-cmY3xhvw43N4q1E7i1JJoECKLpVFb_vTRbGs4A@mail.gmail.com> <874mc9g895.fsf@setec.io> <CAH9QtQGJ73h_O64pKo-YukbxqkjqaQE7cus7iraFO43W+W+vhg@mail.gmail.com> <CABcZeBMcL9+9im2hqLe1KHgbv+0ghrTTV=sK371sVX0ejXOyXA@mail.gmail.com> <CAH9QtQGxVLxo8T3UjaYqUc=3fJSFCrT6PfjVtciv6Ea9xOoy3Q@mail.gmail.com> <CAAF6GDc7mz6u_fu=k4LSqF+5fA-mkTbq0_AZ419WgVruk=BA7Q@mail.gmail.com> <CAH9QtQGti4SdCx2Cd73Moh+0qsx3utvc6trNYCib=BgyLiX=Nw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Mar 2016 18:46:11 -0700
Message-ID: <CABcZeBMdrJpa7P-JKBNerD5Z7DdFH-gSMiGFXVDdGd1keJFSyg@mail.gmail.com>
To: Bill Cox <waywardgeek@google.com>
Content-Type: multipart/alternative; boundary=001a114dad0e3f480a052e0c92f3
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/fthQ5nImt07xhTto0MF6WAWKBb8>
Cc: Scott Schmit <i.grok@comcast.net>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 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: Tue, 15 Mar 2016 01:47:03 -0000

On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox <waywardgeek@google.com>; 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
>
> 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.

-Ekr

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
>