Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)

[Phillip Hallam-Baker <[e-mail]>]

I will forward this to the official comment address as well.

I don't support making HKDF a NIST standard in its current form because
there is a flaw.

Consider the case in which the initial keying material is formed by
concatenating two items, the second of which is a variable length string.

As currently specified, the values for o_key and i_key are the same for a
key k and that same key with a zero byte concatenated. This might not seem
like a big deal but the whole point of defining common building blocks for
crypto is to eliminate all the bear traps we can.

The problem can be eliminated as follows:

1) Generate i_key by padding the key value with byte x before XORing with
the i_mask

2) Generate o_key by padding the key value with byte y (y <> x) before
XORing with the o_mask

This ensures that the values of o_key and i_key will change if zeros are
appended.

This would require us to issue a revised version of HKDF. But I think we
should do just that. Crypto utility functions should be robust under all
known forms of mistreatment. I am probably not the only person who has
multiple salt inputs to a KDF. Fortunately my unit tests caught the issue.