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

[Michael StJohns <[e-mail]>]

On 4/2/2015 10:04 PM, Sean Turner wrote:
> On Apr 02, 2015, at 20:22, Michael StJohns <[e-mail]> wrote:
>
>>   I will note that the author claimed in his paper that the IETF was standardizing this, but I can't find any data suggesting this actually went through the IETF standardization process (vs independent informational RFC submission process).  It did garner some review on the CFRG mailing list, but not to what I normally think of as comprehensive and resolving all comments.
> The pre-5869 draft was AD sponsored by Tim Polk.  The IETF LC can be found here:
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/8rYOi-6zUEljAX4XprWbjP7on0s
I saw that, but that's for Informational, not Standard.  Different bar.

>
> We can refer to it normatively if we want to, we just have to make sure the DOWNREF is explicitly cited, as per RFC 3647.
Yup.  But considering that the difference between HKDF vs the 
combination of SP800-56C plus SP800-108 section 5.2 is the placement of 
the iteration value in what gets HMAC'd and the fact that _the HDKF 
doesn't mix in the total length of the data to be output_, I'd rather 
use the latter cites if we could even if they require an extra paragraph 
to describe the selected sizes of L and i and what goes in to Label and 
Context (basically "info" by another name).

AFAICT, the addition of the L of the output to the data HMAC'd is there 
to force a change to the key stream if the length of the output key 
stream changes and that's probably a good additional security property.  
Other than that, I would say that these are pretty much identical in 
cryptographic composition.

Lastly, I still have hopes one day to remove the requirement for the 
dependency on a HASH function in the handshake and this construct allows 
for a CMAC based MAC.


Again - I can live with HKDF, but I'm unclear of why citing the RFC is a 
better choice given the above comparison.

Thanks - Mike

ps - I will write the paragraph for SP800-56C/108 inclusion if you want 
if we go that way.


>
> spt