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

[Watson Ladd <[e-mail]>]

On Apr 22, 2015 2:49 PM, "Michael StJohns" <[e-mail]> wrote:
>
> 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.

What if the first call for the HMAC key is 128 bits, and we use a broken
variant?

Your example demonstrates why the sane data shouldn't be used for two
different purposes. In fact, it's not clear to me that we can make an HSM
friendly design without telling the HSM which derived values are exportable
and which not.

If we ensured that no value derived by HKDF ever is not used as an
encryption key, this would solve the problem at the cost of some pain with
channel binding. But this would be a very large change.

>
> 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
>>
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>