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

[Hugo Krawczyk <[e-mail]>]

​​


On Mon, Jul 20, 2015 at 12:10 AM, Eric Rescorla <[e-mail]> wrote:

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

​Eric's explanation is correct.
Your question boils down to: Why is finished_secret derived from SS only
and not from ES?

First note that the issue only arises in the known_configuration case since
in other cases ES and SS are the same.
For the known_configuration case there are t
wo important reasons
​ to build on SS and not on ES:
​
1. Only SS can authenticate the handshake as it is the only element to
involve the server's (semi) static private key.
2. One of the main elements to be authenticated by the server (via the
Finished message) is the ServerKeyShare, thus deriving the key for the
Finished message (i.e. finished_secret) from ES (calculated using
ServerKeyShare) would create a circularity issue in the logic of the
derivation.

Note that the derivation of application keys (and other key material
remaining after the end of the handshake) do involve both SS and ES, but in
that case involving ES is crucial to achieve forward secrecy.


Hugo
​


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