TLS 1.3 and its use of HKDF-Extract

Question

HKDF-Extract is defined in RFC 5869 as

  HKDF-Extract(salt, IKM) -> PRK

   Options:
      Hash     a hash function; HashLen denotes the length of the
               hash function output in octets

   Inputs:
      salt     optional salt value (a non-secret random value);
               if not provided, it is set to a string of HashLen zeros.
      IKM      input keying material

In the TLS 1.3 key schedule a secret derived from Handshake Secret is used as the salt input to generate the Master Secret, with the IKM being a string of 0s. However that doesn't seem consistent with HKDF-Extract's definition of salt; that it is non-secret. Is TLS 1.3 using HKDF-Extract incorrectly?

Answer 1

Is TLS 1.3 using HKDF-Extract incorrectly?

No. Unfortunately, the (a non-secret random value) summary is somewhat misleading.

The HKDF RFC allows and basically encourages a secret salt if one is available:

It is worth noting that, while not the typical case, some applications may even have a secret salt value available for use; in such a case, HKDF provides an even stronger security guarantee. An example of such application is IKEv1 in its "public-key encryption mode", where the "salt" to the extractor is computed from nonces that are secret; similarly, the pre-shared mode of IKEv1 uses a secret salt derived from the pre-shared key.

This is because the salt is used as the key for HMAC, and a secret key is a good thing.

I presume they summarised it as non-secret because that's usually the case, and perhaps they expected people to read the entire document. Either way, it should really say (a secret or non-secret random value) for clarity.

Answer 2

As already mentioned in the other answer, the randomness extraction method of HKDF is simply a call to HMAC with the salt as the key and the Input Keying Material as the HMAC input. That is $\mathsf{Extract}(salt, ikm) = \mathsf{HMAC}(salt, ikm)$.

At a high-level, $ikm$ is drawn from a high min-entropy(not necessarily uniform) source, and we want to extract a uniform key out of $ikm$.

Krawczyk states a formal definition for key derivation functions in the HKDF paper: https://eprint.iacr.org/2010/264.pdf. At a high level, this is a security game that asks an adversary to distinguish a random value from one derived from a secret $ikm$. The adversary is also given a description of the IKM source and the salt used in the key derivation. Therefore, the security notion does not demand that the salt is secret.

What's happening then in TLS 1.3? Recall that $\mathsf{Extract}(salt, ikm) = \mathsf{HMAC}(salt, ikm)$. Therefore if $salt$ is not only secret but crucially pseudo-random, this is the normal "secure" invocation of HMAC as a pseudo-random function. And it's a legitimate usage because, at this point, the derived handshake secret is considered pseudo-random, and a PRF produces a pseudo-random output for each new input when keyed with a pseudo-random key. I assume this is an abuse of notation, given that HMAC is the underlying primitive in HKDF. Moreover, since the IKM used for the master secret is a fixed 0 value, it would seem strange to talk about randomness extraction. A fixed value doesn't have much