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

[Michael StJohns <[e-mail]>]

Inline

On 4/22/2015 6:00 PM, Watson Ladd wrote:
>
>
> On Apr 22, 2015 2:49 PM, "Michael StJohns" <[e-mail] 
> <mailto:[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.
>

You are exactly correct.  This needs to be part of the derivation 
information mixins.
>
> 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.
>


Not quite.  There are two things you have to be able to enforce:

1) that the same key can't be used with a KDF and a MAC function. (Since 
the underlying function for the KDF is generally a MAC function, and the 
MAC function is public data where the KDF is private....).   That 
requires strong key typing at the time the key is created along with a 
mechanism that can prevent "master keys" from being used as "integrity 
keys" (and trivially doing the same crypto functions as a MAC function 
and extracting the key stream that way).

and

2) That the same (parts of the) key expansion key stream can't be used 
for different purposes.   So I need to mix in the target types and 
lengths for the key material being produced and I ideally include 
information about whether or not the key material is extractable.

So say I'm generating a master secret from a master secret (e.g. 
pre-master to master).  I include in the KDF mixins an indication that 
the key material being produced is for a single master secret of length 
N.  If I decide instead to produce symmetric operational key material 
(e.g. AES, HMAC, CMAC), then I change the mixins to indicate 2 AES-CCM 
keys of length 128 that are non-extractable (for example)  The key 
expansion stream for the first call is completely disjoint from that 
produced by the second call and an HSM can use the mixin values to set 
its own policy bits.  But those mixins have to be well known and 
standardized.


By the way It turns out that you *can* safely derive both public and non 
public data from a key stream, but not with the current definitions.

What you do is just add an exportable public data type as a mixin 
constant.   So you do


KDF (masterKey, "generic derive", 3 items, [AES-CCM, AES-CCM, 
RANDOM_DATA], [16, 16, 32], [0,0,EXPORTABLE])

....

KDF (Key masterKey, byte[] label, int itemcount, int[] keytypes, int[] 
keyLengths, int[] flags, Key[] keys)


The info section marshalls the three different "key requests" as a 
concatention of 10 integers (count plus 3*3) and and adds that to the 
context or "info" passed in on each pass of the key expansion. All of 
these values passed in provide enforceable policy for the HSM, but 
result in a complete change in the underlying key stream if even one bit 
changes.

Mike






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

"no currently implemented way to differentiate" is closer to the truth.  
We can actually make the math work to cryptographically isolate these 
two cases in a meaningful way.

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