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

[Michael StJohns <[e-mail]>]

I'm going to slice this up a bit and answer in pieces.  Sorry - the 
messages are getting too long.

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
> ​I am completely lost on this length issue. Can you give me a concrete 
> example where TLS 1.3 derives different keys with same label and 
> context but with different output lengths? As said, in TLS 1.3 each 
> label and context is used exactly once. I must be missing something in 
> your argument but I just can't figure what's that.

Hi Hugo -

This isn't about TLS specifically, but about how an HSM makes sure an 
attacker can't extract TLS keys.

Assume that you implement your function in an HSM as you've defined in 
the RFC - without the length term.

Consider that the HSM keys may be USED by the attacker but the HSM is 
set up to prevent extraction - the keys can't be directly extracted . 
(See below for a discussion of how this might happen). And note that for 
a generic KDF interface, you can't ensure that the attacker doesn't use 
the same label and context in his call to use the master key as we 
define for TLS.

Consider that the derivation of the master secret from the pre-master 
secret can be done by both the user and the attacker, but that the 
attacker can request a key length of 1, but with the same label and 
context terms using the same pre-master secret.  Consider that the 
attacker designates this Length 1 key as an HMAC key.

The attacker now uses his version of the derived key as an HMAC key and 
uses it to generate an HMAC tag over a fixed value.  He then compares 
this to 256 generated HMACs over the same fixed value but using the 256 
different possible values of the derived key from above.  When he finds 
a match between one of his 256 HMACs and the HMAC using the derived key, 
he now knows that the value of that derived key.

Consider that _without the length term, a key of length 1 has as its key 
value the same first byte of any key stream of longer length generated 
from the same master key with the same label and context_.

By repeating the steps above, you can extract the master secret in O(1).

If the L term is mixed in by internal mechanism, there is no user 
accessible mechanism to accomplish this.  I.e. using the same secret 
with identical labels and contexts with differing requested output 
lengths produce cryptographically disjoint key material.    If you only 
pass this in as user specified material you don't get this protection.

If you ask me how an attacker can "use" the keys of someone else, 
consider that most versions of PKCS11 support only a PIN based 
authentication, or authentication is done because the HSM is embedded in 
the system.  The thing I'm trying to get to is a model where I can 
demonstrate that key material may not be extracted from an HSM by an 
attacker, even if the attacker has credentials to "use" the keys.

Mike