Re: [TLS] HKDF

[Andrey Jivsov <[e-mail]>]

On 03/23/2015 09:58 PM, Yoav Nir wrote:
>> On Mar 23, 2015, at 9:19 AM, Eric Rescorla <[e-mail]> wrote:
>>
>> As I mentioned in a previous message [0] during the interim we discussed
>> moving from the TLS PRF to HKDF [RFC5869].
>>
>> The general sentiment was:
>>
>> - Move to HKDF
>> - Specify both SHA-256 and SHA-384 (the latter being required for
>>    Suite B)
>>
>> This is also the time when we would want to look at adjusting
>> the key expansion to separate keys and IVs (assuming we still
>> have IVs).
>>
>> Please use this thread to discuss this topic.
>>
> OK, since you’re proposing to abandon the current TLS PRF:
>
> 1. Why? What is wrong with the TLS PRF, and
> 2. If we’re changing it, why not to a fast PRF such as blake2?
>
> Yoav
>
I am somewhat sympathetic to this sentiment. Please also consider that 
KDFs and related processes are standardized by NIST. E.g.:

1. NIST-prescribed way to do KDF, SP 800 108A (it includes HMAC KDF for 
key expansion)

2. NIST DH schemes include KDF, SP 800-56A rev2 (HKDF paper of 2010 
criticizes the first revision; rev 2 is dated 2015)

3. NIST grandfathered TLS KDF in SP 800-135.

4. A very similar SP 800-56C that documents Extraction-then-Expansion, 
where expansion is done with #1 (credits Hugo Krawczyk, among others)

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...