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:
>
>     TLS1.2 uses the Master secret as a key for both the MAC and KDF
>     functions and that needs to change.  Those can't be the same key -
>     and hence your comment about using the same master secret for
>     different derives becomes problematic especially if one of the
>     outputs is to an exporter.
>
>
> ​ The same Master Secret is used to derive multiple keys but these are 
> derived with unique label+context input.​
> ​
> ​ Different derivations *never* use the same label+context.​


Next part of the discussion.

Pretend you're implementing this in an HSM.  How does the HSM enforce 
the "never use same label and context"?  Answer is that it can't and 
there isn't anything currently defined in the label or context that 
allows the HSM to do proper policy protection.

What needs to happen here is to include in the calculation of the key 
stream sufficient values to ensure the key stream is completely 
different if the requested output (e.g. target keys and types) of the 
key stream is different.

Consider as an HSM input to the TLS KDF the label "key expansion", the 
handle for a specific master_secret key and the client and server 
randoms concatenated as the context. Internally, the HSM will 
concatenate the label and context into what you call "info".   The last 
set of inputs to the "key expansion" call to the KDF are the types and 
output lengths of the key material, but those aren't involved in the 
calculation of the key stream.

If you call the HSM version of the KDF with a key, context and label and 
tell it to break things into 2 keys (for AES-CCM) of length 256 bits 
each you will produce a key stream of length 64 bytes.

If I call the HSM version of the same KDF with the same key, context and 
label and tell it to produce a single HMAC-SHA256 key of length 8 bits I 
will get a single byte of key stream which is identical to your call 
above.   Using the TLS 1.2 KDF I can even tell it to not produce any key 
material but to provide me with IVs - which have the same key stream 
material as from your call.  All because the length and types of the 
keys to be produced are not mixed into the key stream production 
calculation.


If I define the TLS KDF as HKDF with a context consisting of (from my 
now expired draft):
    struct {
        uint8    clientRandom[32];      /* ClientHello.random */
        uint8    serverRandom[32];      /* ServerHello.random */
        uint32   keyCount;              /* Num keys to derive */
        KeyType  keyTypes[keycount];
        uint16   keyLengths[keycount];  /* Key lengths in bits */
    } KeyExpansionContext;

the HSM can use the key types and lengths to enforce policy of key 
assignment.  An attacker can no longer assign a part of the key stream 
to shorter keys since the key stream changes if the length of any subkey 
changes.  It can no longer assign a strong mechanism key to a weaker 
mechanism because if the key type changes so does the key stream.    
After discussions on the list, I'd probably also add a uint16 of flags 
per key to allow for some keys to be exported (and allow the HSM to know 
which ones are exportable).

There are other issues, but this gets us closer.

Mike