Re: [TLS] Finished stuffing

[Eric Rescorla <[e-mail]>]

On Wed, Sep 7, 2016 at 8:25 AM, David Benjamin <[e-mail]>
wrote:

> On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla <[e-mail]> wrote:
>
>> On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud <
>> [e-mail]> 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
>>>> <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tls [2]
>>>>>
>>>>
>>>> _______________________________________________
>>>>  TLS mailing list
>>>>  [e-mail]
>>>>  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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>