Subject: [TLS] Key Hierarchy

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Sep 2015 16:58:12 -0700

https://github.com/tlswg/tls13-spec/pull/248

Folks,

Hugo Krawczyk, Hoeteck Wee, and Bjorn Tackmann suggested a revision
to the key hierarchy that separates out the computation of the MS from the
computation of the keys that are derived from ES and SS. Specifically,
xES and xES are to be used to derive their respective traffic keys and
intermediate values mES and mES which are then used with HKDF-Extract
to generate MS.

Aside from some analytic advantages, this also allows us to use
the HKDF-Extract and HKDF-Expand APIs from RFC 5869 which is
convenient (it's also compatible with all-in-one HKDF APIs).

The PR is at:
https://github.com/tlswg/tls13-spec/pull/248

I think this is a good change, but comments welcome.

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Sun, 20 Sep 2015 18:56:44 -0700

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

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Sep 2015 20:02:59 -0700

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

> the HKDF-Extract(mSS, mES) operation. What does this mean for the security

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 22 Sep 2015 18:22:44 -0400

> What are the analytic advantages?

​The advantages are: a cleaner separation of keys derived from ES and SS, a
simpler proof argument (via the explicit functional separation of extract
and expand steps), and the ability to represent the whole key derivation
scheme via the extract/expand steps or via full HKDF calls, whichever is
more convenient (the latter gives significant flexibility to an
implementation depending on its API to the full HKDF function or to its
extract and expand components).

> the HKDF-Extract(mSS, mES) operation. What does this mean for the security

​It seems that when you say "an authenticated value" you actually mean "an
unauthenticated value". If I got it wrong let me know.
Assuming this interpretation of your question let me point out that the
value mSS is server-authenticated by virtues of g^s being authenticated
(via a server's signature or a server-configuration​) hence it complies
with the RFC (and paper).

> NSA Suite B Profile in this respect.

​Ekr answered this. If you still feel something is wrong let us know.

Hugo
​

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>