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

[Michael StJohns <[e-mail]>]

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>
>     Given SP800-108 and SP800-56C were published before your paper 
>     and the RFC and have pretty much identical math (except as I
>     noted), why shouldn't we use those cites instead of the RFC?  E.g.
>     is there any cryptographic improvement in RFC5869 vs the other two?
>
>
> ​ SP 800-108 is a framework and set of recommendations, not a 
> specific, unique KDF function. HKDF follows this framework and NIST 
> found this sufficiently important to document this in a separate 
> document SP 800-56C (which explicitly includes HKDF as an instantiation)​
> ​ .​

You didn't actually answer the base question of "is there any 
cryptographic improvement...."?

With respect to the above, SP800-56C says to use one of the SP800-108 
expansions.

Third paragraph of section 4 of SP800-56C:
> The key expansion step uses the key derivation key KDK and other 
> information exchanged and/or pre-shared, such as identifiers for the 
> involved parties, protocol identifiers, and the labels of the derived 
> keys, as the input to an approved key derivation function specified in 
> SP 800-108 [4] to produce secret keying material KM of a desired length L.

What I think you're referring to is (last paragraph of the same section):
> IETF RFC 5869 [10] describes an instantiation of the above 
> extraction-then-expansion key derivation procedure using HMAC for the 
> extraction and expansion steps. For extensive rationale on the key 
> derivation through the extraction-then-expansion procedure specified 
> in this Recommendation see [11].

But that appears to be a reference to base material rather than an 
endorsement of it as an approved function.

Cryptographically, there isn't any difference I can see except the L term.


If I were to do this I would say in TLS:


"The TLS KDF is the extraction function specified in SP800-56C combined 
with the "KDF in Feedback Mode" mode (Section 5.1) of SP800-108 with the 
following specifications:  For SP800-56C, the shall be no salt and the 
extraction function shall be as appropriate for the selected TLS PRF.  
For SP800-108, the KDF PRF shall be the MAC function of the selected TLS 
PRF with a default of HMAC-SHA256. The L and i terms shall be expressed 
as network byte order 32 bit unsigned integers.  The Label shall be the 
defined TLS label expressed as ASCII bytes, and the Context shall be the 
context defined for that specific Label encoded as per normal TLS rules. 
The ordering of the terms processed by the PRF in step 4a is as 
indicated in SP800-108 section 5.1."

Later, Mike