Re: [TLS] HKDF

[Hugo Krawczyk <[e-mail]>]

​Here are some clarifications about HKDF that can help better understanding
its
rationale and use in (OP)TLS.

Note: all places where I say random it can (and sometimes should) be
replaced by
pseudo-random meaning indistinguishable from a uniform random string.

- HKDF is standardized by NIST (as an *approved* KDF mechanism) in
SP-800-56C
  where it is explicitly stated that HKDF complies with this standard:
  "IETF RFC 5869 [10] describes an instantiation of the above
  extraction-then-expansion key derivation procedure using HMAC for the
  extraction and expansion steps. For extensive rationale on the key
derivation
  through the extraction-then-expansion procedure specified in this
  Recommendation see [11]." For those interested, [11] appeared in Crypto
2010
  and is here http://eprint.iacr.org/2010/264.

- HKDF uses a two-step mechanism by which one first extracts randomness
from a
  possibly non-uniform secret input to create a uniformly random string
that is
  then used with a regular PRF to generate keying material. In (OP)TLS we
denote
  the two steps as HKDF-Extract and HKDF-Expand. The rationale of the
extraction
  part is to concentrate the "secret entropy" of the input on a single
strong
  cryptographic key (from which more keys can be derived).

- HKDF uses HMAC for both extract and expand but it could use, in
principle, any
  regular PRF (including those from NIST) for expansion. Extraction is
trickier
  since it is not a generic property of PRFs. The reason to use HMAC for it
is
  that the HMAC construction has properties that support the extraction
  functionality under reasonable cryptographic assumptions.

- Skipping the extraction property would require keying a PRF with a
non-uniform
  key in which case the usual properties of PRF cannot be guaranteed as
these
  properties assume a uniform random key. In TLS with RSA this was not a
problem
  since the key transported under RSA was chosen as a random uniform string.
  When using a DH key or passphrase this is not the case.

- Beyond the important cryptographic reasons for the extraction step, this
also
  solves the problem of having to adapt the size of the secret input to
that of
  a length of the key in the PRF: for example, how do you key AES-256 with a
  point on a 512 elliptic curve? Even with a 256 curve you would require
point
  compression which you may or may not want to use (I hope this comment
does not
  open a discussion of EC point representations :-).

- The expansion function of HKDF is HMAC-based and is ESSENTIALLY THE SAME
as in
  previous TLS. It even has the same feedback mode that TLS uses to expand
a key
  (the exact inputs to the iterations changes a bit but nothing major).

- There is no need for ultimate performance in the key derivation in TLS.
These
  operations are relative minor compared to the algebraic operations.

- There is nothing that ties HKDF to OPTLS in a fundamental way other than
it
  supports the provability of the protocol, hence improving the confidence
on
  its design. In particular, it supports a clean hierarchical key
derivation for
  all the protocol modes.

Hugo
​


On Tue, Mar 24, 2015 at 8:16 AM, Ilari Liusvaara <
[e-mail]> wrote:

> On Tue, Mar 24, 2015 at 06:39:43AM -0500, Yoav Nir wrote:
> >
> > > On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <[e-mail]>
> wrote:
> > >
> > > Please note that at least some of these can be FIPS 140 tested (in
> particular, TLS PRF). Suite B expects the use of these approved KDFs.
> > >
> > > While NIST is perhaps too prolific with these, I feel that we should
> look into standard KDFs. There are test vectors, verifications systems,
> existing implementations…
> >
> > If such a KDF is needed for Suite-B, then it makes sense for Suite-B
> ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM.
> >
> > Why not include a different PRF in those suites that have
> non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever
> signature scheme CFRG are going to recommend?
>
> Or even special Suite B ciphersuites. I think there are only 2 of
> those.
>
> - ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
> - ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384
>
> The basic idea being: They who care can implement that.
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>