Re: [TLS] Finished stuffing

[Joseph Salowey <[e-mail]>]

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
>>>
>>> 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
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>