Re: [TLS] Key Hierarchy

[Eric Rescorla <[e-mail]>]

On Sun, Sep 20, 2015 at 6:56 PM, Brian Smith <[e-mail]> wrote:

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

As I said, a clearer separation between the input keying material
used to make traffic keys and that used to make keys which
are then input into HKDF.



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

I'm going to defer this to Hugo and Hoeteck.



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

Why? Note that the next thing we are going to do is use this keys to
generate
keys which are generally <= 256-bits.

It's also worth noting that previous versions of TLS behaved this way as
well.

-Ekr