Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

[Hugo Krawczyk <[e-mail]>]

Here are a few clarifications regarding HKDF and its use in TLS 1.3 in
response
to recent emails (including those under the "HSM-friendly Key Computation"
thread). I will not touch on anything specific to HSM or PKCS11 since I know
little about these and the recent exchange on these issues has not helped me
understanding these things any better (but rather confuse me more).

Let me start with the issue of whether we should be using the HKDF-Extract
and
HKDF-Expand separately or only use HKDF as a single function (which
internally
operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for
the
latter approach (single function) as it deals with HKDF as a black box.
But there are also advantages to calling these two components separately,
and
TLS 1.3 provides some good examples for that. First, HKDF is built to
output as
many keys as needed from a single HKDF operation, but in TLS we are deriving
multiple keys from the same keying material through separate applications
of the
expand part. In such a case it is more natural to apply extract once and
apply
expand several times (with different info fields!). For example, Master
Secret
is derived using a single Extract operation but it is then used in three
different Expand operations for deriving other keys (application traffic
keys,
export master secret, and resumption master secret). Second, when one
starts with
a strong key then the Extract step can be skipped making it convenient to be
able to call Expand directly. Third, it is convenient to call Expand
directly as
a PRF for computing the Finished message. Lastly, and not least, it makes
the
key derivation logic more explicit which helps conveying the rationale of
each
operation and helps those analyzing the protocol (now and in the future).

My recommendation is to keep the Extract and Expand separation for the
moment,
in particular due to the last point, so we can see more clearly the logic
while
still setting the missing details of the protocol. When the whole picture is
clear we can revisit this point.

On other issues:

- This should be obvious but worth repeating: All calls to HKDF-Expand MUST
use
  a non-empty info field binding the derived key(s) to a unique context (in
the
  case of TLS this is usually a label and a cumulative session-hash).

- It was suggested that the length of derived keys should be part of the
input
  to key expansion. If desired, this length can be entered through the info
  field of HKDF but I would be very careful not to derive two different keys
  where the only difference in the 'info' values is the key length. If the
two
  keys happen to be of the same length one would end up with two keys that
are
  identical.

- One of the emails raises the issue of using random salt, as recommended
by RFC
  5869. Note that the RFC recommendation also indicates that the salt value
  should be something that is authenticated during the protocol, or
otherwise it
  can be selected by the adversary. This authentication needs to happen
  independently of the key being derived using this salt. For example, one
  should be careful not to incur in a circular logic, e.g. deriving a key
  mackey=HKDF(salt, info) and then using mackey to authenticate the salt by
  computing MAC(mackey, salt). This is why the proposed TLS 1.3 key
derivation
  scheme does not use nonces as salt.

- Someone said: "In an ideal world we would all use the same KDFs rather
than
  inventing a new one for each protocol." This was exactly the goal of HKDF,
  namely, provide a single KDF that can serve different protocols,
requirements
  and settings. The interested reader can consult my Crypto 2010 paper
  https://eprint.iacr.org/2010/264
  for a very detailed treatment of key derivation in general and HKDF in
  particular,and why this one design fits many different uses. TLS 1.3 is a
  perfect demonstration of the versatility of HKDF as it is used as a random
  oracle, randomness extractor and PRF, depending on the key material being
  derived. See the next item for an example.

- Another issue raised in recent email exchange is the way to merge the
  semi-static value g^xs (where s is the semi-static server's private key
and x
  the ephemeral client's private key) with the ephemeral value g^xy.
  This is done by first extracting a key from g^xs as
PRK1=HKDF-extract(0,g^xs)
  and then extracting PRK2=HKDF-extract(PRK1,g^xy).
  Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a
random
  oracle as needed in the proof of security. Then PRK2 is derived with
salt=PRK2
  for the following reason. If g^xs is not exposed (the typical case) then
this
  HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the
less
  demanding property from HKDF).  If g^xs is revealed by compromise of the
  server's semi static private key s (after the conclusion of the
handshake, as
  in the forward-secrecy setting), then PRK1 is actually an authenticated
random
  and non-secret salt so you use HKDF as a randomness extractor.
  In other words, each use of HKDF uses the minimal cryptographic
assumption one
  can have depending on the context of derivation.

- Finally, there has been a long discussion related to the derivation of
both
  secret and non-secret material (the latter for IVs). I can't say how this
  works with HSMs, PKCS11 or other standards, but from the cryptographic
point
  of view doing this "mixed" derivation of secret and non-secret values is
not a
  problem as long as HMAC is not broken as a PRF.

Hugo