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

[Hugo Krawczyk <[e-mail]>]

Mike, thanks a lot for the clear explanation!
I think I can now understand the issues you were raising. Sorry for my
ignorance.

One thing I (think I) understand now is that this discussion had little to
do with HKDF (specifically) but rather has to do with the inputs to the KDF
function defined by the calling protocol, say TLS 1.3.

We can define TLS 1.3 so that calls to HKDF will always include a info
string composed of:
label, context (say, session-hash) and the length L of the output key
material.
Now, in the HSM implementation you will read the values label and context
from the user's input but L will  be added by the HSM itself by calculating
the length of the required key. In non-HSM implementations the software
will add L.

I am perfectly ok with adding L, or any other value, to the HKDF info input
in the TLS 1.3 spec if the WG is interested in doing so.

Hugo



On Sun, Apr 26, 2015 at 4:52 PM, Michael StJohns <[e-mail]>
wrote:

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