Re: [TLS] crypto computations & lifetimes clarifications (was: TLS 1.3 - method to request uncached shared secrets)

[Eric Rescorla <[e-mail]>]

On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett <[e-mail]>
wrote:

> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> > I think perhaps you have misunderstood the forward secrecy properties of
> the
> > current draft. Unlike TLS 1.2 and previous, the current draft has a
> separate
> > resumption master secret which is independently derived from the master
> > secret used for the connection keys in the original connection. This
> means
> > that if you don't resume the connection, you have forward secrecy for the
> > original connection regardless of whether the server stores the session
> in
> > the session cache or sends the client a ticket.
>
> We've got lots of keys and secrets now. Could you please clarify the exact
> points where these are each to be discarded? If I am understanding it
> correctly, the master_secret, prior intermediate secrets, and
> finished_secret are to be discarded as soon as the keys, resumption_secret,
> and possibly exporter_secret (which currently has no explanation in the
> doc) are derived, the handshake is finished, and we're ready for
> application traffic? It would help if you provided a table/chart laying out
> the timeline of secret & key lifetimes, from derivation to discard. It
> should state in the spec explicitly what needs to be kept around for how
> long and require things be discarded as soon as viable.
>

Yes, I can do something along these lines.



> I think these various values need to be named more consistently in the doc
> to make searching for them easier. For example, "resumption_secret" is used
> in the computation part but the words "resumption master secret" are used
> when actually using this value. (also noted in issue #191 by Martin
> Thomson) I've pushed a small PR to correct this case along with a few
> tweaks that I think makes it a bit clearer.
> https://github.com/tlswg/tls13-spec/pull/205
>
> Also, some other questions about various computations:
>
> https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-7.1
> https://tlswg.github.io/tls13-spec/#key-schedule
>
> HKDF(,,,) doesn't seem to be fully defined here, just
> HKDF-Expand-Label(,,,) which is based on HKDF-Expand(,,) from RFC 5869.
> Could you please clarify this?
>

Yes.



> Why is finished_secret derived from extracted static secret instead of
> master_secret?


The rationale here is that the Finished message also serves to authenticate
the server's ephemeral DH share (when in known_configuration mode) and
because the master secret depends on the ephemeral DH keys, this creates
an odd authentication logic. Hugo can expand on this some more, perhaps.



> Are there two finished_secret in the event that the client sends a
> certificate?
>

No, this shouldn't be necessarily. You just use the first one. I'll try to
clarify.



> The computation of verify_data could probably be moved up to the same
> section so this is all in the same place. Am I correct in reading that it
> could be simplified a bit? (e.g. HKDF-Expand-Label(master_secret,
> finished_label, handshake_hash, L) without the extra HMAC currently defined
> for verify_data)


See above.

-ekr