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

[Michael StJohns <[e-mail]>]

I'm top posting my own post....


Sean et al:

After spending a bit more time looking at things from the view point of 
HSMs and cryptographic isolation, I'm now of the opinion that HKDF 
shouldn't be specified.

The specific issue is the difference between HDKF step 2 and the 
SP800-108 expansion functions.   Cryptographically, these specifications 
are close to identical except for the inclusion of a mandatory length 
term in the mixin values.   Without this term, a key stream produced 
from the same mixins (e.g. same label, randoms etc) for the same master 
key will be identical regardless of the length of the output key(s).

E.g. if one call to the KDF has a target key of AES128 and another call 
to the KDF using the same master key and mixins has a target key of a 
single octet HMAC key, the first octet of the AES key will be identical 
to that single octet HMAC key.    Using this construct with increasingly 
longer HMAC keys (thanks to HMAC's impedance matching function) will 
eventually reveal each and every byte of the AES key.

In an HSM, there is no way to differentiate these two different KDF 
calls for legitimacy.

If the KDF mixes in the length of the to be output key material, then 
any change in the length of the requested key changes the entire key stream.

I see three different approaches to fix this - 1) specify the SP800-56C 
with SP800-108 HMAC, 2) add the length term to the HKDF RFC and 
republish it, 3) ensure one or more length terms are included in the 
"info" for ALL KDF calls for TLS and document why.


Mike



On 4/3/2015 1:45 AM, Michael StJohns wrote:
> 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
>