Re: [TLS] Finished stuffing

[Benjamin Kaduk <[e-mail]>]

I made a few notes on the pull request.  Generally, I support the
change, but I get the sense that it may aid the cryptographic properties
if we keep the resumption_context and do not overload the resumption_psk
as much.

I have a slight (i.e., unjustified) preference for doing
ClientHello-with-block-of-zeros rather than prefix-of-ClientHello.  (Is
there a reason to require this extension to be the last one with
block-of-zeros?  Clearly there is for prefix-of-ClientHello.)

-Ben

On 09/06/2016 11:49 PM, Joseph Salowey wrote:
> 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]
> <mailto:[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]
>     <mailto:[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]
>         <mailto:[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
>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_615&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=ukqGqua3EOfqImRb0EFPRRxMv7Hgom3t_5Ki4OvDG8M&e=>
>
>             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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/tls
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=wIZYtT4TzI4oljhi8_PX1pf95lodfWq4WmQBUXX5Q7g&e=>
>
>
>     _______________________________________________
>     TLS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=IwfxQnHf5o1ACITZiQQEOKnbhWK40rJ7uWbCfhm0pSE&s=wIZYtT4TzI4oljhi8_PX1pf95lodfWq4WmQBUXX5Q7g&e=>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls