Re: [TLS] Finished stuffing

Eric Rescorla <ekr@rtfm.com> Wed, 07 September 2016 23:19 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 ABDBD12B095 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 16:19:41 -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 OaVXDl0M_zCV for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 16:19:38 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 92D2912B010 for <tls@ietf.org>; Wed, 7 Sep 2016 16:19:38 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id g192so18721170ywh.1 for <tls@ietf.org>; Wed, 07 Sep 2016 16:19:38 -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=W6BVOblMjS7tSHc7ywlV959+byiHbJkwIJ0hp5+zwMQ=; b=rbNhmUL8qkc/O30DIxlagJacIFNee3Yqhv0B/HqRQtT4y0fXAOU72ft38JBbIC3wVE nlC5WqmN9szH1xwRxQmNF1GB5OGGpAmPgRbl7KJunSK43ggTzekMUuxL6W+SHVgwCQe6 ZTm3bQBRR57q2cI7Zl6SsFZ+xvc7+lNFBugh5GpzxZFGGyJ4efibwEtrZfWY8wWVwKHV 7ITgjFwxN8o7LGMOysHJoz7wUAVeLCj0VmcoQl94q0Um0u298fp8qCo0lC75O7180Xy3 qIBC+1SqbZr8KOd/Ry8TgZwJZASodngoXw4FpE65EwhpQvvtb+5SeoAFfN3/g75Cc/Go KxrA==
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=W6BVOblMjS7tSHc7ywlV959+byiHbJkwIJ0hp5+zwMQ=; b=HTBq0ahgdYH1wHc6Htvgiaw4BYqO+S4VfhtJPHizmrxtrMRdLNDK8hisyPRPV9/En9 pqUSXwWhUx5GVvYP3R/Yx6D+cb0YOQAH0NAXyHkg1PieYPuxIqtTyvinn8rM5fFq6K+l ss07peIa0Ns3YaiXYEz0UqR9Fd+xAaVzncDIf0hEDK+N63+Y9tB+vFagyLSJHccE1Poa 4Xn4cgE2doOMFvH43AR+5fDhK0BG6bcB+eODKY/lGmqt274veoA2f7Pcr3dlwrK8MO46 bItK3QTEQ3UzLbn0k5juSRwAKPi041elG15cAz1erfJ2a3kqvfoMbGpn4x6BMgQN80ty WBYw==
X-Gm-Message-State: AE9vXwOq+qoNfjncvz2fPgGzPxrQxzuwwazhdOaqEtz1NJc5pu9UsA0ymCfg82FADn4TnpiK/bLbASAwuwhgEQ==
X-Received: by 10.13.220.1 with SMTP id f1mr41940256ywe.289.1473290377654; Wed, 07 Sep 2016 16:19:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.32.70 with HTTP; Wed, 7 Sep 2016 16:18:56 -0700 (PDT)
In-Reply-To: <CADi0yUNs1+j73seG653epbSk52OnTAxnw6sLCK8kJkZqS902nw@mail.gmail.com>
References: <CABcZeBNqs+6SYsA9SnED8nWkUXifSPuF4gBdRG-gJamtWmxWNw@mail.gmail.com> <CABcZeBP890QrcbpGR9Ht2RkfHShavkkDmvvKPP+81x8Bz+SeDA@mail.gmail.com> <CAF8qwaCVyRrSm-XtL6Jd_VKD9qGmCJNFJW1GZVjmidsr3DnW_Q@mail.gmail.com> <CAOgPGoD8YEr=+c8eG+YZ=6nSvFB2uk7MiKNgN7Z=wg7ihAUhzg@mail.gmail.com> <e7729a05efe1d204bc6ee2ab2f59ae9d@maxg.info> <CABcZeBM2wqgxdsLonLzTtPChyZ14KSMwzy1HQukTL_5gXXWLmw@mail.gmail.com> <CAF8qwaB=JJ_5V9RuJNdqSmj1c=yNMANzKBksM-6TLtfnf6j57g@mail.gmail.com> <CABcZeBMhthzSWbJa_Gkt6MB-RfrAOq=VT6GU9i7GTefq0Gj2Fw@mail.gmail.com> <CADi0yUNs1+j73seG653epbSk52OnTAxnw6sLCK8kJkZqS902nw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 7 Sep 2016 16:18:56 -0700
Message-ID: <CABcZeBP1hNEbxbxwxQN===CT7XdBXwQ87MG5ibsOJDS7i4gBqw@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Content-Type: multipart/alternative; boundary=94eb2c0809f09ca236053bf3255f
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ip-k1CNgBbK7MGQp7dCfvB8fzH8>
Cc: Antoine Delignat-Lavaud <antoine@delignat-lavaud.fr>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Finished stuffing
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: Wed, 07 Sep 2016 23:19:42 -0000

On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <hugo@ee.technion.ac.il>
wrote:

> I don't  understand the proposal.
> Are you proposing to eliminate resumption_context (RC) from All its
> current uses and replace it with the hello_finished extension?
>

Yes.



> Or is this to affect only certain uses of RC? Which ones?
>
One important property of RC is that it serves as a binding with the
> original context that generated a resumption PSK, in particular a binding
> with the server's identity (certificate). This is not achieved by the
> hello_finished extension, is it?
>

It is supposed to do so. The reasoning is:

- RMS is unchanged and therefore derived from the server certificate
- The HelloFinished computation is HKDF(F(RMS), <ClientHello>) and
therefore also is derived from the server certificate.

Is that insufficient.


I also have a problem with names. "Resumption context" is very explicit
> about providing, well, resumption context.
> "Hello_Finished", in turn, means nothing.
> Also, RC may better match the notion of "binder" hence more naturally
> requiring collision resistance, while all Finished uses in TLS (1.3 and
> before) have a MAC functionality (for which, say, 128 bits are good enough)
> and it would be better not to abuse them for other uses.
>

Two points about this:

1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash is
SHA-256, so I believe we have enough strength here. We could of course
require a minimum size.
2. I wouldn't object to changing names here, of course.

Best,
-Ekr


> Anyways, maybe this is just the result of my misunderstanding of the
> proposal.
>
> Hugo
>
>
> On Wed, Sep 7, 2016 at 11:26 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Wed, Sep 7, 2016 at 8:25 AM, David Benjamin <davidben@chromium.org>
>> wrote:
>>
>>> On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>> On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud <
>>>> antoine@delignat-lavaud.fr> wrote:
>>>>
>>>>> Regarding whether the placeholder zeros should be part of the
>>>>> transcript for the stuffed finished, an argument against it is that it
>>>>> violates the incremental nature of the session hash. If the hash stops
>>>>> before the placeholder, it can be resumed with the computed finished;
>>>>> otherwise, it must be rolled back.
>>>>>
>>>>
>>>> This isn't a big deal for me (or I think any other implementor) either
>>>> way, because of the actual way we compute the hash.
>>>>
>>>
>>> To expand on that, because the final PRF hash is not known at the time
>>> we send ClientHello, most implementations I've seen just buffer the full
>>> transcript before this point.
>>>
>>> But one could also keep a rolling hash of all the supported PRFs
>>> (there's all of two of them if you lose TLS 1.1 and below), so I think
>>> that's a good argument for using the prefix rather than zeros. For
>>> implementations keeping a buffer, I don't think it matters, so let's keep
>>> both strategies happy.
>>>
>>
>> This is certainly fine with me.
>>
>> -Ekr
>>
>>
>>>
>>> David
>>>
>>>
>>>
>>>> -Ekr
>>>>
>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Antoine
>>>>>
>>>>>
>>>>> Le 2016-09-07 05:49, Joseph Salowey a écrit :
>>>>>
>>>>>> Hi Folks,
>>>>>>
>>>>>> The chairs want to make sure this gets some proper review.   Please
>>>>>> respond with comments by Friday so we can make some progress on this
>>>>>> issue.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> J&S
>>>>>>
>>>>>> On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin
>>>>>> <davidben@chromium.org> wrote:
>>>>>>
>>>>>> I think this is a good idea. It's kind of weird, but it avoids
>>>>>>> giving the early Finished such a strange relationship with the
>>>>>>> handshake transcript. Also a fan of doing away with multiple PSK
>>>>>>> identities if we don't need it.
>>>>>>>
>>>>>>> As a bonus, this removes the need to route a "phase" parameter into
>>>>>>> the traffic key calculation since we'll never derive more than one
>>>>>>> epoch off of the same traffic secret. Combine that with the
>>>>>>> two-ladder KeyUpdate and we no longer need any concatenation or
>>>>>>> other label-munging at all. Simply use labels "key" and "iv" and the
>>>>>>> record-layer just exposes a single UseTrafficSecret function which
>>>>>>> saves the traffic secret (for KeyUpdate), derives the traffic keys,
>>>>>>> and engages the new AEAD in one swoop without mucking about with
>>>>>>> phases, traffic directions, whether we are client or server, etc.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla <ekr@rtfm.com> wrote:
>>>>>>>
>>>>>>> I should also mention that this makes the implementation a fair bit
>>>>>>> simpler because:
>>>>>>>
>>>>>>> 1. You can make all the decisions on the server side immediately
>>>>>>> upon receiving the ClientHello
>>>>>>> without waiting for Finished.
>>>>>>> 2. You don't need to derive early handshake traffic keys.
>>>>>>>
>>>>>>> >From an implementor's perspective, this outweighs the messing around
>>>>>>> with the ClientHello buffer.
>>>>>>> -Ekr
>>>>>>>
>>>>>>> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> I have just posted a WIP PR for what I'm calling "Finished Stuffing"
>>>>>>>
>>>>>>> https://github.com/tlswg/tls13-spec/pull/615 [1]
>>>>>>>
>>>>>>>
>>>>>>> I would welcome comments on this direction and whether I am missing
>>>>>>> anything important.
>>>>>>>
>>>>>>> OVERVIEW
>>>>>>> This PR follows on a bunch of discussions we've had about the
>>>>>>> redundancy
>>>>>>> of Finished and resumption_ctx. This PR makes the following changes:
>>>>>>>
>>>>>>> - Replace the 0-RTT Finished with an extension you send in the
>>>>>>> ClientHello *whenever* you do PSK.
>>>>>>> - Get rid of resumption context (because it is now replaced by
>>>>>>> the ClientHello.hello_finished.
>>>>>>>
>>>>>>> RATIONALE
>>>>>>> The reasoning for this change is:
>>>>>>>
>>>>>>> - With ordinary PSK you don't get any assurance that the other side
>>>>>>> knows the PSK.
>>>>>>>
>>>>>>> - With 0-RTT you get some (subject to the usual anti-replay
>>>>>>> guarantees) via the Finished message.
>>>>>>>
>>>>>>> - If we were to include the 0-RTT Finished message in the handshake
>>>>>>> transcript, then we wouldn't need the resumption context because
>>>>>>> the transcript would transitively include the PSK via the
>>>>>>> Finished.
>>>>>>>
>>>>>>> So the natural thing to do would be to always send 0-RTT Finished
>>>>>>> but unfortunately:
>>>>>>>
>>>>>>> 1. You can't just send the 0-RTT Finished whenever you do PSK
>>>>>>> because
>>>>>>> that causes potential compat problems with mixed 1.3/1.2 networks
>>>>>>> (the same ones we have with 0-RTT, but at least that's opt-in).
>>>>>>>
>>>>>>> 2. You also can't send the 0-RTT Finished with PSK because you can
>>>>>>> currently offer multiple PSK identities.
>>>>>>>
>>>>>>> The on-list discussion has suggested we could relax condition #2 and
>>>>>>> only have one identity. And we can fix condition #1 by stuffing the
>>>>>>> Finished in an extension (with some hacks to make this easier). This
>>>>>>> PR enacts that.
>>>>>>>
>>>>>>> FAQS
>>>>>>> - What gets included in the handshake transcript?
>>>>>>> The whole ClientHello including the computed hello_finished
>>>>>>> extension.
>>>>>>>
>>>>>>> - Isn't this a hassle to implement?
>>>>>>> It turns out not to be. The basic reason is that at the point
>>>>>>> where
>>>>>>> the client sends the ClientHello and the server processes, it
>>>>>>> doesn't
>>>>>>> yet know which Hash will be chosen for HKDF and so NSS (and I
>>>>>>> believe
>>>>>>> other stacks) buffers the ClientHello in plaintext, so hashing
>>>>>>> only
>>>>>>> part of it is easy. I've done it in NSS and this part is quite
>>>>>>> easy.
>>>>>>>
>>>>>>> POTENTIAL VARIATIONS/TODOs
>>>>>>> There are a number of possible variations we might want to look at:
>>>>>>>
>>>>>>> 1. Moving obfuscated_ticket_age to its own extension (out of
>>>>>>> early_data_indication). This provides additional anti-replay
>>>>>>> for the CH at the 0.5RTT sending point. I believe we should
>>>>>>> make this change.
>>>>>>>
>>>>>>> 2. Tweaking the data to be hashed to just hash the ClientHello
>>>>>>> prefix without the 0-filled verify_data. This is not
>>>>>>> significantly
>>>>>>> harder or easier to implement and basically depends on whether
>>>>>>> you prefer the invariant of "always hash complete messages" or
>>>>>>> "always hash valid pieces of transcript". See above for notes
>>>>>>> on buffering.
>>>>>>>
>>>>>>> 3. Allow multiple PSKs. Technically you could make this design
>>>>>>> work with >1 PSK but stuffing multiple verify_data values in
>>>>>>> the ClientHello. E.g,,
>>>>>>>
>>>>>>> opaque FinishedValue<0..255>;
>>>>>>>
>>>>>>> struct {
>>>>>>> FinishedValue finisheds<0..2^16-1>;
>>>>>>> } HelloFinished;
>>>>>>>
>>>>>>> Based on the list discussion, it seems like nobody wants >1 PSK,
>>>>>>> so I think one is simpler; I just wanted to note that these
>>>>>>> changes weren't totally coupled.
>>>>>>>
>>>>>>> 4. External context values. Several people have pointed out that it
>>>>>>> might be convenient to have an external context value hashed
>>>>>>> into the transcript. One way to do this would be to include
>>>>>>> it under the Finished. That's not difficult if people want to,
>>>>>>> with the default being empty.
>>>>>>>
>>>>>>> 5. Hugo brought up on the list that we need to make very clear that
>>>>>>> the "hello_finished" is being used to bind the handshakes and
>>>>>>> that it depends on collision resistance. I have not forgotten
>>>>>>> this
>>>>>>> and text on that point would be appreciated.
>>>>>>>
>>>>>>> Comments welcome.
>>>>>>> -Ekr
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> TLS mailing list
>>>>>>> TLS@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/tls [2]
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>>  TLS mailing list
>>>>>>  TLS@ietf.org
>>>>>>  https://www.ietf.org/mailman/listinfo/tls [2]
>>>>>>
>>>>>>
>>>>>>
>>>>>> Links:
>>>>>> ------
>>>>>> [1] https://github.com/tlswg/tls13-spec/pull/615
>>>>>> [2] https://www.ietf.org/mailman/listinfo/tls
>>>>>>
>>>>>> _______________________________________________
>>>>>> TLS mailing list
>>>>>> TLS@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> TLS@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>