Re: [TLS] Finished stuffing

Eric Rescorla <ekr@rtfm.com> Wed, 07 September 2016 15:26 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 5FF3112B1E2 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 08:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 wO-8UMZRSMZ0 for <tls@ietfa.amsl.com>; Wed, 7 Sep 2016 08:26:55 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 89C4612B005 for <tls@ietf.org>; Wed, 7 Sep 2016 08:26:55 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id g5so7109279yba.2 for <tls@ietf.org>; Wed, 07 Sep 2016 08:26:55 -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=Bg4VtMcl1b8QDm5itUCzRdLPHf5HCxoX6+UoBcxHyA8=; b=KIf+n78AeMPSvUx9s/EiO18n9sVucI7D0t04k2MEZTI5Kz3RqSk4CNZ21Q2JSHa2SX rtlyCA9Uk8d4vCokhebVpz+DreFQl+xOCREdQGd+M/v5huVKvujefYKWNcnMNCJEaUPa IEJG1JJ1bHa6MGwImtTDV6o+QPPtseHxqj0pBH4TUcCqaIeOzmJIbeo1NMw0tqJGbFlp Qi4wkhzYM1pJ5GkhieahixDmzP1F2Q4qY8qH67fElmHmz3FGACUN45HEkOCRemEpDMyh uDU2s8OVYPadAAbmrNY1qv82AgueGQ2r1Lwj9EKCQo8hSZctuGWeC38UMcDEqP6KJNWu v8LQ==
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=Bg4VtMcl1b8QDm5itUCzRdLPHf5HCxoX6+UoBcxHyA8=; b=LLAtDsYgyzX5DixeC6R1+nWcFM4kkNx8rFrJBNurJO+DykhpHbMbvHbgh7KqOxy3IH f33Ap9exmhBm6hvIiii509Z98eNi+AeIGqVP3sCxz0/a1B827F/UOBat8SkUVLRKicAW UFEs42KWr964OdTY0cgDR7RDGXMHZ7jEWunEpwaMf0f6nkiBOj8cH/wjOxe4C06djiwH kSuapKjePdIZH1RG5xmDub7CNcwGv/vfuuKc5ayb4r10Gx27kOxP6oWkfgJgi8sz5Lxo uXRmJop0M7ILzP4PTb/pv/HLCxgOpxB+gpe0c1qOrUTchYRrIyfWgFcY/e8vH3d3h/np WlOA==
X-Gm-Message-State: AE9vXwPwgh1SjDBZAc2M+KfCvApWR8RnEVRb5WfMSue+MSHPZ2YeUpqbSwM8EhXo+gZ3aXPJX9JEaCWCX9uzpg==
X-Received: by 10.37.215.80 with SMTP id o77mr16775741ybg.6.1473262014654; Wed, 07 Sep 2016 08:26:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.112.66 with HTTP; Wed, 7 Sep 2016 08:26:14 -0700 (PDT)
In-Reply-To: <CAF8qwaB=JJ_5V9RuJNdqSmj1c=yNMANzKBksM-6TLtfnf6j57g@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 7 Sep 2016 08:26:14 -0700
Message-ID: <CABcZeBMhthzSWbJa_Gkt6MB-RfrAOq=VT6GU9i7GTefq0Gj2Fw@mail.gmail.com>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=94eb2c0689ac0baf35053bec8b04
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LVa0C8SjsJA-U7W3gX9XfyzRIkk>
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 15:26:58 -0000

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