Re: [TLS] Key Hierarchy

[Brian Smith <[e-mail]>]

On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla <[e-mail]> wrote:

> https://github.com/tlswg/tls13-spec/pull/248
>
> Aside from some analytic advantages
>

What are the analytic advantages?

Also, a question that applied even to the older design: I remember the an
HKDF paper and the HKDF paper stating that before it is safe to use a value
as an HKDF salt, it must be authenticated. But, in both the old and new
designs it seems like an authenticated value is being used as the salt in
the HKDF-Extract(mSS, mES) operation. What does this mean for the security
analysis?

One of the notes in the new design draws some attention to the strange fact
that we compress the output of the ECDHE operation to the length of a
digest function that is independent of the length of the ECDH keys used.
For example, if we used P-256 in the ECDHE operation for a AES-128-GCM
cipher suite, we'd compress the output to 256 bits using HKDF-Extract with
SHA-256. But, if we used P-521 in the ECDHE operation for the same cipher
suite,  we'd still compress the output to 256 bits using HKDF-Extract with
SHA-256. That seems wrong. I would guess it makes more sense to choose the
HKDF digest algorithm based on the size of the ECDHE key. Note that in the
NSA Suite B Profile for TLS, they fixed this by requiring a more rigid
relationship between the ECDHE key size and the cipher suite than what TLS
requires. See [1]. I think it's worth considering whether the current
(older and newer) design makes is better or worse than a design like the
NSA Suite B Profile in this respect.

[1] https://tools.ietf.org/html/rfc6460#section-3.1.

Cheers,
Brian
-- 
https://briansmith.org/