Make the PRF hardware module friendly

[martinthomson]

Mike StJohns points out several ways in which the current PRF is inimical to clean hardware module design in an email and in a draft.

[martinthomson]

Mike's proposal:

My PRF proposal is to change the PRF to a counter based PRF

prf_step (i, secret, label, context, total_length) =
     MAC (secret, i + label + 0x00 + context + total_length); // i and total_length are uint32 big endian
prf_data (secret, label, context, total_length) =
     CONCAT (i = 1 to CEIL(total_length/blocksize), prf_step (i, secret, label, context, total_length))[0..total_length-1];

For deriving keys, you use the above construct and a master secret. For using this for the production of random public data (e.g. IVs), you use a '0' key of the appropriate length. The externalized functions are the KDF function (which passes in a key) and the DRBG (deterministic random bit generator) (which doesn't pass in a key), but the underlying implementation is common. The PRF function is never externalized.

[briansmith]

Mike's suggestion is to base the KDF on SP800-108. However, I thought IETF decided to try to move new protocols to HKDF [1]. Selection of an SP800-108-based mechanism would require a clear justification for why it is used instead of HKDF.

[1] https://tools.ietf.org/html/rfc5869

[ekr]

Consensus at interim.

1. Label + length is enough.
2. Add:
   • length + label
   • all labels will now have "TLS 1.3, " in front of them.

[ekr]

Done