Re: [TLS] Finished stuffing

[Eric Rescorla <[e-mail]>]

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