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

From: Sean Turner <[email-masked]>
Date: Wed, 1 Apr 2015 14:00:45 -0400

This message is to confirm the consensus reached @ the IETF 92 TLS session in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an HKDF-based PRF (see http://datatracker.ietf.org/doc/rfc5869/?include_text=1).

Please indicate whether or not you agree with the consensus by 2015-04-17.  If not, please indicate why.  Also, please note that we’re interested in uncovering new issues not rehashing issues already discussed.

Thanks - J&S

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 01 Apr 2015 14:14:34 -0400

On Wed 2015-04-01 14:00:45 -0400, Sean Turner wrote:
> This message is to confirm the consensus reached @ the IETF 92 TLS
> session in Dallas and at the TLS Interim in Seattle to make the TLS
> 1.3 PRF be an HKDF-based PRF (see
> http://datatracker.ietf.org/doc/rfc5869/?include_text=1).
>
> Please indicate whether or not you agree with the consensus by
> 2015-04-17.  If not, please indicate why.  Also, please note that
> we’re interested in uncovering new issues not rehashing issues already
> discussed.

I agree with the room's consensus to move to an HKDF-based PRF for TLS
1.3.

  --dkg

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 1 Apr 2015 14:53:07 -0400 (EDT)

----- Original Message -----
> This message is to confirm the consensus reached @ the IETF 92 TLS session in
> Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an
> HKDF-based PRF (see
> Please indicate whether or not you agree with the consensus by 2015-04-17.
> If not, please indicate why.  Also, please note that we’re interested in
> uncovering new issues not rehashing issues already discussed.

I believe the question is totally unwarranteed. No-one has presented any argument
on why the TLS PRF is not sufficient for its purpose. The only arguments presented
are theoretical advantages of HKDF, which are fine, but do they add value to TLS?
Does the advantages of HKDF translate into weaknesses of the TLS PRF?

So no matter the output of that poll the result will be an uneducated guess. In all cases
it is alarming to see the easiness with which the protocol is being rewritten completely.
Now its only similarity with TLS 1.2 is the TLS acronym. Would that rewrite bring value
in par with the efford needed for the rewrite? Would it make us safer in 2030 or are we
simply apply yesterday's technology today?

regards,
Nikos

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 1 Apr 2015 12:14:44 -0700 (PDT)

On Wed, April 1, 2015 11:00 am, Sean Turner wrote:
> This message is to confirm the consensus reached @ the IETF 92 TLS session
> in Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an
> HKDF-based PRF (see

  I agree with the consensus to adopt HKDF.

  Dan.

---

From: Russ Housley <[email-masked]>
Date: Wed, 1 Apr 2015 15:19:33 -0400

The hum in the room showed overwhelming support for HKDF.

One detail that was not discussed because we were running out of time is important to me (and may be important to others).  SHA-256 would be the MTI.  Is an alternative hash function chosen based on the cipher suite or some other mechanism?

Russ

On Apr 1, 2015, at 2:00 PM, Sean Turner wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Brian Smith <[email-masked]>
Date: Wed, 1 Apr 2015 09:32:22 -1000

> Please indicate whether or not you agree with the consensus by 2015-04-17.  If not, please indicate why.  Also, please note that we’re interested in uncovering new issues not rehashing issues alrea…

There's a lot of ambiguity in what "HKDF-based" means.

I agree that new versions of TLS should use HKDF-Extract, then
HKDF-Expand, with suitable parameters, as recommended in RFC5869, to
build the keyblock that will be partitioned into keys. I also agree
that TLS extractor should use HKDF in a similar way for new versions
of TLS.

Cheers,
Brian

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 1 Apr 2015 22:48:50 +0300

On Wed, Apr 01, 2015 at 03:19:33PM -0400, Russ Housley wrote:
> 
> One detail that was not discussed because we were running out of
> time is important to me (and may be important to others).  SHA-256
> would be the MTI.  Is an alternative hash function chosen based on
> the cipher suite or some other mechanism?

In TLS 1.2 and 1.3-current, the main PRF-hash is designated by
the ciphersuite. I have not seen any proposals to change this.

Then there is signature hash, which is negotiated using
extensions.

-Ilari

---

From: Sean Turner <[email-masked]>
Date: Wed, 1 Apr 2015 17:21:03 -0400

> Does the advantages of HKDF translate into weaknesses of the TLS PRF?

Both ekr and I queued the whole discussion up with there’s "nothing really wrong" with the PRF as far as we know.  The discussion in Dallas starts about 2:31:15 on audio stream - listen for a muffled ekr saying "oh god":
http://www.ietf.org/audio/ietf92/ietf92-oak-20150326-0900-am1.mp3

At about 2:34:47 of the audio stream, Hugo discuses some of the “sub-optimal” aspects of the current PRF.

> simply apply yesterday's technology today?

I guess I don’t follow - the PRF changed in previous versions and we kept the “TLS” moniker.

spt

---

From: Sean Turner <[email-masked]>
Date: Wed, 1 Apr 2015 17:27:46 -0400

>> the cipher suite or some other mechanism?

I’m sure you saw the other thread where we’re discussing MTI, but if not SHA-256 was the proposed MTI.

> the ciphersuite. I have not seen any proposals to change this.

Yeah there’s been no propose to change this.  Granted @ the interim we did discuss hard coding SHA-256 but knowing there will be profiles that will want to use something else we decided hard coding it was not a great idea.

spt

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Apr 2015 00:52:08 +0300

I support this proposal.

I agree that the weakness with the current PRF is theoretical, but the cost is not significant and theoretical attacks sometimes morph into pretty demos with funky acronyms. Let’s not go there.

Yoav

> On Apr 1, 2015, at 9:00 PM, Sean Turner <[email-masked]> wrote:
>

---

From: Michael StJohns <[email-masked]>
Date: Thu, 02 Apr 2015 20:22:38 -0400

> Please indicate whether or not you agree with the consensus by 2015-04-17.  If not, please indicate why.  Also, please note that we’re interested in uncovering new issues not rehashing issues alrea…

I have a large preference to move to a different KDF than we're 
currently using. (And to limit the output of said KDF to key material 
and nothing else).  Deprecating the current TLS KDF will help with 
resolving some HSM related security issues.

I have a medium preference that that KDF be counter based rather than 
recursive (as is the current PRF and HKDF).  I've got a sneaking 
suspicion that doing so would be cleaner to implement in hardware as the 
only field changing with every call to HMAC is that of the counter.

I have a small preference that we cite a more widely accepted/reviewed 
standard than RFC5869 (which is basically the authors republication of 
their original paper or vice versa).  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.

I wish David et al had ended up completing the work on 
https://datatracker.ietf.org/doc/draft-irtf-cfrg-kdf-uses/, but what's 
there suggests that we could select one of those instead and get a more 
widely acceptable KDF.

All that said, I won't oppose HKDF.

Mike

---

From: Sean Turner <[email-masked]>
Date: Thu, 2 Apr 2015 22:04:43 -0400

On Apr 02, 2015, at 20:22, Michael StJohns <[email-masked]> 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

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.

spt

---

From: Michael StJohns <[email-masked]>
Date: Fri, 03 Apr 2015 01:45:49 -0400

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 03 Apr 2015 08:49:24 +0200

> At about 2:34:47 of the audio stream, Hugo discuses some of the “sub-optimal” aspects of the current PRF.

Ok, if I can summarize the argument presented against the current PRF is
the fact that it works well when the input (pre_master_secret) is
uniform but not otherwise. So in the words of the speaker it works well
for the RSA ciphersuites because the premaster secret is simply a random
nonce, but not in the other ciphersuites. My words now. The other
ciphersuites are Diffie-Hellman and Elliptic curve Diffie-Hellman. In
these cases the pre-master-secret is the negotiated key. I've seem
several cryptographic proofs assuming that the negotiated key in DH and
ECDH is uniform, but indeed that may not be correct, and let's accept
the speaker's argument.

So we have a problem in the TLS handshake, and we have decided in an
afternoon to replace the PRF with what the speaker suggested which is
HKDF. That also happens to be the speaker's invention. That's pretty
much expected of course. Shouldn't, however, the WG investigate whether
there are better alternatives to fix the problem? Shouldn't other
cryptographers asked to say their opinion on the fix and the issue?
That's what the WG did with Salsa20 proposal, asked the CFRG. Maybe
there are even more issues in the current PRF we don't know. In any
case, HKDF is not bad choice, it is a good choice and already used in
IKEv2. However, I am not an expert in PRFs, but I still see many design
similarities in HKDF and the TLS PRF. So I wonder whether there are
better from these two choices which we will never know if we only listen
to one opinion.

> I guess I don’t follow - the PRF changed in previous versions and we kept the “TLS” moniker.

That's not the comment I make. My main concern is "Would that rewrite
bring value in par with the efford needed for the rewrite?". In that
particular case with HKDF; is HKDF the best choice we can do now to keep
us with a good PRF until 2030?

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 3 Apr 2015 13:06:56 +0300

On Fri, Apr 03, 2015 at 08:49:24AM +0200, Nikos Mavrogiannopoulos wrote:
> nonce, but not in the other ciphersuites.

Can be proven to work well. Big difference.

Furthermore, I think any attack here is at least one of:
- Banana attack.
- Requires seriously breaking the prf-hash.
- Requires seriously breaking other things than just PRF.

And "seriously breaking" means deprecate/replace this ASAP.

> My words now. The other

Furthermore, if prf-hash is even close to being collision-resistant
(which it has to be or some other stuff breaks), I really don't see
how feeding DH or ECDH outputs could cause problems.

Basically, if inputs are adversarial or overly long, you have worse
problems than what those inputs do to the PRF.

> better from these two choices which we will never know if we only listen

I know two problems with TLS PRF:

- Label/Seed separation.
  -> The way HKDF is used in the WIP has the exact same mistake.
  -> Could be fixed by maiking label to be ASCIIZ/UTF8Z.
     -> Close enough for many(?) existing implementations.
- Problems with key >1 input block.
  -> HKDF trips the problem with key >1 output block (which is more often)
  -> Big enough keys are mainly seen with (ff)DHE (or P-521 with SHA-256).

> us with a good PRF until 2030?

I think one could make PRF that is better than both TLS-PRF and HKDF,
but I don't know anything that really is.

-Ilari

---

From: Michael StJohns <[email-masked]>
Date: Wed, 22 Apr 2015 17:49:28 -0400

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.

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 Apr 02, 2015, at 20:22, Michael StJohns<[email-masked]>  wrote:
>>
> 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 
> 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.
>
> 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
>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Apr 2015 15:00:13 -0700

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).
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.
>>>>  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.
>>> 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.
if we go that way.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 23 Apr 2015 13:25:28 -0400

Inline

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

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 24 Apr 2015 17:31:51 -0400

Here are a few clarifications regarding HKDF and its use in TLS 1.3 in
response
to recent emails (including those under the "HSM-friendly Key Computation"
thread). I will not touch on anything specific to HSM or PKCS11 since I know
little about these and the recent exchange on these issues has not helped me
understanding these things any better (but rather confuse me more).

Let me start with the issue of whether we should be using the HKDF-Extract
and
HKDF-Expand separately or only use HKDF as a single function (which
internally
operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for
the
latter approach (single function) as it deals with HKDF as a black box.
But there are also advantages to calling these two components separately,
and
TLS 1.3 provides some good examples for that. First, HKDF is built to
output as
many keys as needed from a single HKDF operation, but in TLS we are deriving
multiple keys from the same keying material through separate applications
of the
expand part. In such a case it is more natural to apply extract once and
apply
expand several times (with different info fields!). For example, Master
Secret
is derived using a single Extract operation but it is then used in three
different Expand operations for deriving other keys (application traffic
keys,
export master secret, and resumption master secret). Second, when one
starts with
a strong key then the Extract step can be skipped making it convenient to be
able to call Expand directly. Third, it is convenient to call Expand
directly as
a PRF for computing the Finished message. Lastly, and not least, it makes
the
key derivation logic more explicit which helps conveying the rationale of
each
operation and helps those analyzing the protocol (now and in the future).

My recommendation is to keep the Extract and Expand separation for the
moment,
in particular due to the last point, so we can see more clearly the logic
while
still setting the missing details of the protocol. When the whole picture is
clear we can revisit this point.

On other issues:

- This should be obvious but worth repeating: All calls to HKDF-Expand MUST
use
  a non-empty info field binding the derived key(s) to a unique context (in
the
  case of TLS this is usually a label and a cumulative session-hash).

- It was suggested that the length of derived keys should be part of the
input
  to key expansion. If desired, this length can be entered through the info
  field of HKDF but I would be very careful not to derive two different keys
  where the only difference in the 'info' values is the key length. If the
two
  keys happen to be of the same length one would end up with two keys that
are
  identical.

- One of the emails raises the issue of using random salt, as recommended
by RFC
  5869. Note that the RFC recommendation also indicates that the salt value
  should be something that is authenticated during the protocol, or
otherwise it
  can be selected by the adversary. This authentication needs to happen
  independently of the key being derived using this salt. For example, one
  should be careful not to incur in a circular logic, e.g. deriving a key
  mackey=HKDF(salt, info) and then using mackey to authenticate the salt by
  computing MAC(mackey, salt). This is why the proposed TLS 1.3 key
derivation
  scheme does not use nonces as salt.

- Someone said: "In an ideal world we would all use the same KDFs rather
than
  inventing a new one for each protocol." This was exactly the goal of HKDF,
  namely, provide a single KDF that can serve different protocols,
requirements
  and settings. The interested reader can consult my Crypto 2010 paper
  https://eprint.iacr.org/2010/264
  for a very detailed treatment of key derivation in general and HKDF in
  particular,and why this one design fits many different uses. TLS 1.3 is a
  perfect demonstration of the versatility of HKDF as it is used as a random
  oracle, randomness extractor and PRF, depending on the key material being
  derived. See the next item for an example.

- Another issue raised in recent email exchange is the way to merge the
  semi-static value g^xs (where s is the semi-static server's private key
and x
  the ephemeral client's private key) with the ephemeral value g^xy.
  This is done by first extracting a key from g^xs as
PRK1=HKDF-extract(0,g^xs)
  and then extracting PRK2=HKDF-extract(PRK1,g^xy).
  Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a
random
  oracle as needed in the proof of security. Then PRK2 is derived with
salt=PRK2
  for the following reason. If g^xs is not exposed (the typical case) then
this
  HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the
less
  demanding property from HKDF).  If g^xs is revealed by compromise of the
  server's semi static private key s (after the conclusion of the
handshake, as
  in the forward-secrecy setting), then PRK1 is actually an authenticated
random
  and non-secret salt so you use HKDF as a randomness extractor.
  In other words, each use of HKDF uses the minimal cryptographic
assumption one
  can have depending on the context of derivation.

- Finally, there has been a long discussion related to the derivation of
both
  secret and non-secret material (the latter for IVs). I can't say how this
  works with HSMs, PKCS11 or other standards, but from the cryptographic
point
  of view doing this "mixed" derivation of secret and non-secret values is
not a
  problem as long as HMAC is not broken as a PRF.

Hugo

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Apr 2015 08:34:58 +0300

On Fri, Apr 24, 2015 at 05:31:51PM -0400, Hugo Krawczyk wrote:
> Here are a few clarifications regarding HKDF and its use in TLS 1.3 in response

Actually, for me, that HSM thread actually clarified what the actual requirements
are (which lets one minimize distruption).

> Let me start with the issue of whether we should be using the HKDF-Extract and
> HKDF-Expand separately or only use HKDF as a single function (which internally
> operates HKDF-Extract and HKDF-Expand). There is an obvious advantage for the
> But there are also advantages to calling these two components separately, and
> TLS 1.3 provides some good examples for that. First, HKDF is built to output as
> multiple keys from the same keying material through separate applications of the
> expand part. In such a case it is more natural to apply extract once and apply
> expand several times (with different info fields!). For example, Master Secret
> different Expand operations for deriving other keys (application traffic keys,
> export master secret, and resumption master secret). Second, when one starts with
> able to call Expand directly. Third, it is convenient to call Expand directly as
> a PRF for computing the Finished message. Lastly, and not least, it makes the
> key derivation logic more explicit which helps conveying the rationale of each

Some models derive even more things out of (handshake) MS, e.g. one model does:
- s2c_appMS.
- eMS
- Unique
- c2s_appMS.
- rPMS
 
> My recommendation is to keep the Extract and Expand separation for the moment,
> in particular due to the last point, so we can see more clearly the logic while
> - This should be obvious but worth repeating: All calls to HKDF-Expand MUST use
>   a non-empty info field binding the derived key(s) to a unique context (in the
> - It was suggested that the length of derived keys should be part of the input
>   where the only difference in the 'info' values is the key length. If the two
>   keys happen to be of the same length one would end up with two keys that are
>   identical.

Well, there would still be string input of what the key is (otherwise e.g. rPMS
and eMS might up ending being the same, which isn't desirable).

> - One of the emails raises the issue of using random salt, as recommended by RFC
>   should be something that is authenticated during the protocol, or otherwise it
>   computing MAC(mackey, salt). This is why the proposed TLS 1.3 key derivation

With fixed salts, the HKDF extract function is essentially H1(H2(x)), where
H1 and H2 are H, but with different (pseudorandom) IVs.

Also, handshake hashes are very hard to control to any significant degree (or
invoking HKDF with bad salt is the least of your worries).

E.g. Suppose prf-hash is 256-bit MD5-equivalent-security. The handshake
security just breaks catastrophically against active attacks (passive attacks
are another matter).

>   semi-static value g^xs (where s is the semi-static server's private key and x

"the semi-static server's private key"??? There is no "the key". There's the old
semi-static key (which may not be available), and the new semi-static key. And
the two may or may not be the same key, and those keys may not even be available.

Also, in certain conditions, not mixing in DH result with the old key actually
leads to an attack (mixing the new one does not help here).

Also, I heard some implementers complaining about mixing the new one, and after
calculating the time penalty, I can easily understand (it is pretty sizable).

>   This is done by first extracting a key from g^xs as PRK1=HKDF-extract(0,g^xs)
>   Here is the logic: PRK1 is extracted from g^xs using HKDF(0,...) as a random
>   oracle as needed in the proof of security. Then PRK2 is derived with salt=PRK2
>   for the following reason. If g^xs is not exposed (the typical case) then this
>   HKDF use only requires treating HKDF(PRK1,...) as a PRF (essentially the less
>   server's semi static private key s (after the conclusion of the handshake, as
>   in the forward-secrecy setting), then PRK1 is actually an authenticated random
>   In other words, each use of HKDF uses the minimal cryptographic assumption one

If it is the new one, it is not properly authenticated (have I mentioned how nasty
even capturing the proper assumptions is?).

> - Finally, there has been a long discussion related to the derivation of both
>   works with HSMs, PKCS11 or other standards, but from the cryptographic point
>   not a  problem as long as HMAC is not broken as a PRF.

Well, looks like that problem got sorted out (by getting the "HSM folks" to
actually state the actual requirements).

-Ilari

---

From: Andrey Jivsov <[email-masked]>
Date: Fri, 24 Apr 2015 22:59:53 -0700

> H1 and H2 are H, but with different (pseudorandom) IVs.

Ilari beat me on this, but I also made this observation. In more details:

According to intended use of HKDF, HKDF-Extract is this:

    HMS = HKDF-Extract( salt=0, IKM=g^xy )

Which is:

    A. HMAC( 0, g^xy ) = Hash( opad || Hash( ipad || g^xy ) ).

The two invocations of the Hash() begin with hashing fixed values, so 
one can re-write the A as

    A1: Hash1( Hash2( g^xy ) ),

which can be rewritten as

    A2: Hash3( g^xy ) = Hash( opad || Hash( ipad || g^xy ) )

Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic 
hash of g^xy and that's the only contribution of g^xy in HKDF.

For comparison, TLS 1.2 does the following in the first step:

    B. Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "master secret" + 
ClientHello.random + ServerHello.random) ) );

It would be amusing to see a case when A2 is secure, while B is not.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Apr 2015 09:16:15 +0300

On Fri, Apr 24, 2015 at 10:59:53PM -0700, Andrey Jivsov wrote:
> The two invocations of the Hash() begin with hashing fixed values, so one
> can re-write the A as
> 
> Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic hash of
> g^xy and that's the only contribution of g^xy in HKDF.
> 

Actually, in TLS 1.2, if one uses FFDHE, or if one somehow manages to
use excessively large ECC keys (most likely P-521 with SHA-256),
then the g^xy is replaced by Hash(g^xy).

Also, with extended master secret (needed to fix all sorts of security
problems from lack of CRK):

Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "extended master secret" +
handshake_hash) ) );

-Ilari

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 14:58:58 -0400

Inline below.

> operation and helps those analyzing the protocol (now and in the future).

What you're doing as far as I can tell is optimizing implementation at 
the cost of requiring special interfaces.

One of the ways we've gotten to the point where TLS key material can't 
actually be kept secret in an HSM is by generalizing the concept of a 
PRF into a KDF and a MAC.    What we need to do is have a MAC function 
and a KDF function and understand what the inputs to those are.

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.

Internally, an HSM MAY choose to retain the output of the extract phase 
as cached material (and in fact taking the master secret, doing the 
impedance match of the extract phase and replacing the master secret 
with the reduction still pointed to the master secret handle may be what 
a particular implementation does).  But that's an implementation 
discussion, not a KDF input/output discussion.

>   case of TLS this is usually a label and a cumulative session-hash).

All calls to HKDF *should* use a non-empty label and context field, but 
that's tied more to the specific use than anything else.  This isn't 
something that needs to be enforced by the security module as the crypto 
will cause different streams to be generated with different labels and 
contexts.

Except for the problem of the Length term.   Same label and context but 
with different output lengths will have the same prefixed key stream.
>   keys happen to be of the same length one would end up with two keys 

The term you use in your paper and the RFC is

T(N) = HMAC-Hash(PRK, T(N-1) | info | N) where N is expressed as a 
single octet in the concatenation operation.

You can include the length term in info, but it won't be enforced by the 
HSM and depending on the format of the INFO field could actually be 
spoofed as this is all user supplied info that isn't known to be related 
to the actual desired output length.

Instead HKDF should be updated to:

T(N) = HMAC-Hash (PRK, T(N-1) | info | N | L) where L is the number of 
bits of desired key stream expressed as a UINT32 in NBO *is* enforceable 
by the HSM as it is a known field (size and position).

NIST SP800-56C (which was standardized after the RFC and references your 
paper) describes the equivalent of your extract phase and then refers to 
SP800-108 and allows any of those to be used in the expansion phase.  
ALL of the possible alternatives - counter, feed back (and the evil 
double pipeline) include the length term in the per-block expansion.

E.g.  the feedback expansion uses:

K(i) := PRF (KI, K(i-1) {|| [i]2 }|| Label || 0x00 || Context || [L]2)

Where PRF is equivalent to your HMAC-HASH,  KI is the PRK, [i]2 is the 
same as N, "Label || 0x00 || context" is equivalent to info and L[2] is 
the length of the desired output.

HKDF is equivalent to NISTSP800-56C with an expansion phase of NIST 
SP800-108, section 5.2 where the length of i is a single octet, where 
the ordering of the terms is slightly different and where the L term is 
omitted.

The inclusion of L as a mandatory term in the expansion means that any 
change in L changes the entire key stream.  That is NOT the case with 
HKDF as defined in the RFC.

See section 7.5 of SP800-108 for a discussion of key separation 
especially paragraph (2) and why this is important.

>   scheme does not use nonces as salt.

I believe that is the correct approach.
>
> - Someone said: "In an ideal world we would all use the same KDFs 
> rather than
>   inventing a new one for each protocol."
That was me.  But what I said was that we should use standard KDFs, not 
reinvent new ones.

> This was exactly the goal of HKDF,

Given SP800-108 and SP800-56C were published before your paper  and the 
RFC and have pretty much identical math (except as I noted), why 
shouldn't we use those cites instead of the RFC?  E.g. is there any 
cryptographic improvement in RFC5869 vs the other two?

>   of view doing this "mixed" derivation of secret and non-secret 
> values is not a

Umm....  I don't actually understand what you said here.

The issue is that you can't use the same key for different purposes if 
you want to enforce key security.  Even though the underlying construct 
for a KDF is an HMAC function, if you can ensure - in an enforceable 
manner - that a master secret can only be used for key expansion and an 
integrity key is only used for a MAC function (including the HMAC over 
data) and that pseudo-random data does not depend on either of these 
keys (i.e. they are  cryptographic isolated) then you can build an HSM 
that can actually do its job. There are other related issues (e.g. the 
outputs of a KDF getting tagged with appropriate key types, lengths and 
exportability).

All that means is that you want three different functions: KDF (key 
expansion), MAC (finished message signature)  and RBG (IV/Nonce 
production), and that you enforce the type of inputs to them.  The 
underlying cryptographic constructs can be the same or similar, but we 
need to stop conflating them as needing to be identical.

Mike

---

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 26 Apr 2015 16:20:49 -0400

On Sun, Apr 26, 2015 at 2:58 PM, Michael StJohns <[email-masked]>
wrote:

> What you're doing as far as I can tell is optimizing implementation at the
> cost of requiring special interfaces.
>
> actually be kept secret in an HSM is by generalizing the concept of a PRF
> into a KDF and a MAC.    What we need to do is have a MAC function and a
> KDF function and understand what the inputs to those are.
>
> 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.​

> Internally, an HSM MAY choose to retain the output of the extract phase as
> cached material (and in fact taking the master secret, doing the impedance
> match of the extract phase and replacing the master secret with the
> reduction still pointed to the master secret handle may be what a
> particular implementation does).  But that's an implementation discussion,
> not a KDF input/output discussion.
>

​Is this discussion geared to define the KDF mechanism for TLS 1.3?
If so, can you say what exactly you are proposing to do?
​

> that's tied more to the specific use than anything else.
>

​Agreed. All calls to HKDF that produce cryptographic keys for use in the
protocol MUST use a non-empty label and context field and that's what we
do.
​

> This isn't something that needs to be enforced by the security module as
> the crypto will cause different streams to be generated with different
> labels and contexts.
>

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

> T(N) = HMAC-Hash(PRK, T(N-1) | info | N) where N is expressed as a single
> octet in the concatenation operation.
>
> HSM and depending on the format of the INFO field could actually be spoofed
> as this is all user supplied info that isn't known to be related to the
> actual desired output length.
>

 Adding the length is not a solution to spoofing attacks- it will not
differentiate between keys of the same length.
You cannot compensate via the KDF for unauthorized access to the HSM. If
the HSM doesn't enforce an access policy, it is the HSM problem, not
something to solve via the KDF or via TLS 1.3 spec.
​

> bits of desired key stream expressed as a UINT32 in NBO *is* enforceable by
> the HSM as it is a known field (size and position).
>
> SP800-108 and allows any of those to be used in the expansion phase.  ALL
> of the possible alternatives - counter, feed back (and the evil double
> pipeline) include the length term in the per-block expansion.
>
> same as N, "Label || 0x00 || context" is equivalent to info and L[2] is the
> length of the desired output.
>
> SP800-108, section 5.2 where the length of i is a single octet, where the
> ordering of the terms is slightly different and where the L term is
> omitted.
>
> change in L changes the entire key stream.  That is NOT the case with HKDF
> as defined in the RFC.
>
> See section 7.5 of
> ​​
> SP800-108 for a discussion of key separation especially paragraph (2) and
> why this is important.
>
> ​I agree with section 7.5 and HKDF, and its use in TLS 1.3, fully complies
with it. There is no mandatory use of length as input. It is certainly
allowed but not mandated. And when allowing it, it is accommodated via the
equivalent of the 'info' ​

​field:

*"different input data strings (e.g. Label || 0x00 || Context || [L]2)
shall be used for different executions".*Length is an example and not even
listed in the explicit examples at the top of page 19.
​

> RFC and have pretty much identical math (except as I noted), why shouldn't
> we use those cites instead of the RFC?  E.g. is there any cryptographic
> improvement in RFC5869 vs the other two?
>

​SP 800-108 is a framework and set of recommendations, not a specific,
unique KDF function. HKDF follows this framework and NIST found this
sufficiently important to document this in a separate document SP 800-56C
(which explicitly includes HKDF as an instantiation)​
​.​

> Umm....  I don't actually understand what you said here.

​We are definitely having difficulties understanding each other. I'm trying
my best.

Hugo

​

>
> The issue is that you can't use the same key for different purposes if you
> want to enforce key security.  Even though the underlying construct for a
> KDF is an HMAC function, if you can ensure - in an enforceable manner -
> that a master secret can only be used for key expansion and an integrity
> key is only used for a MAC function (including the HMAC over data) and that
> pseudo-random data does not depend on either of these keys (i.e. they are
> cryptographic isolated) then you can build an HSM that can actually do its
> job.  There are other related issues (e.g. the outputs of a KDF getting
> tagged with appropriate key types, lengths and exportability).
>
> underlying cryptographic constructs can be the same or similar, but we need
> to stop conflating them as needing to be identical.
>
> Mike
>
>
> Hugo
>
>
>
> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 26 Apr 2015 16:28:21 -0400

Indeed, HKDF-extract(0, g^xy) is equivalent to ​Hash( opad || Hash( ipad ||
g^xy ) )
but that is only for computing an intermediate key which is then used to
key HKDF-expand for actual key derivation where the input to this
derivation includes the 'info' field (label + digest of handshake messages).

You are right that in the case of Master Secret, the key derivation in TLS
1.2 is more complicated-looking (actually, it is very similar to deriving
Master Secret using full HKDF instead of HKDF_Extract only) but just being
complicated-looking is not a guarantee of additional security (*). A well
structured uniform scheme as HKDF that serves multiple purposes in a single
design is much cleaner and amenable to analysis. Security by obscurity (or
by "complicatity") is never a good idea. And the multi-purpose properties
of HKDF are not just academic advantages, but  a property of HKDF that
serves TLS 1.3 very well, for example to strengthen the application keys by
making them depend on both long-term and ephemeral keying material.

Hugo

(*) Just for fun, if you compare Hash( opad || Hash( ipad || g^xy ) ) to
your preferred
​ ​
Hash(g^xy ^ opad || Hash( (g^xy ^ ipad)
​ ) you can note that if g^xy is longer than the hash block, your security
gets limited to that block length while in the former this is not
necessarily the case. I am not suggesting that this is a practical
advantage of the former, just giving it as an example of why complicating
things do not necessarily help and many times can actually hurt. The more
structural issue here is not to use a non-uniform key, as  g^xy may be, as
a HMAC key directly.​

On Sat, Apr 25, 2015 at 1:59 AM, Andrey Jivsov <[email-masked]> wrote:

>    A2: Hash3( g^xy ) =
> Hash( opad || Hash( ipad || g^xy ) )
>
> Therefore, HKDF-Extract( 0, g^xy ) should be viewed as deterministic hash
> of g^xy and that's the only contribution of g^xy in HKDF.
>
>    B.
> Hash(g^xy ^ opad || Hash( (g^xy ^ ipad) || "master secret" +

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 16:52:07 -0400

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

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 19:50:38 -0400

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>     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 
> ​ 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

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 19:55:44 -0400

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>
>
>     All calls to HKDF *should* use a non-empty label and context
>     field, but that's tied more to the specific use than anything else.
>
>
> ​ Agreed. All calls to HKDF that produce cryptographic keys for use in 
> the protocol MUST use a non-empty label and context field and that's 
> what we do.

Some clarification here:

For HKDF as a generic function, I meant "SHOULD" in its normal meaning.  
Implementations of HKDF can permit a null label and context field and 
will get what they expect from that.

For HKDF as a the KDF for TLS, TLS will assign labels and associate 
contexts for specific usages and those are going to be non-null.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 20:01:48 -0400

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>
>     You can include the length term in info, but it won't be enforced
>     by the HSM and depending on the format of the INFO field could
>     actually be spoofed as this is all user supplied info that isn't
>     known to be related to the actual desired output length.
>
>
> You cannot compensate via the KDF for unauthorized access to the HSM. 
> If the HSM doesn't enforce an access policy, it is the HSM problem, 
> not something to solve via the KDF or via TLS 1.3 spec.
> ​

Adding the length is not a solution to spoofing attacks and does not 
differentiate between keys of the same length, but it will differentiate 
between keys of _different_ lengths which is where the attack comes 
in.   The problem is not in the math of the KDF, but in the HSMs ability 
to determine how to convert key stream material into concrete keys in a 
manner that doesn't subject them to attack.

If I have a key that's derived from another key, I would like that it 
not be trivial for an attacker who has access to the HSM to extract that 
derived key.  I believe that making the change to add the length makes 
it difficult to do such extraction and apparently(?) so did the 
reviewers of SP800-108(?).

Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 20:06:46 -0400

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>
>     See section 7.5 of
>     ​ ​
>     SP800-108 for a discussion of key separation especially paragraph
>     (2) and why this is important.
>
> ​ I agree with section 7.5 and HKDF, and its use in TLS 1.3, fully 
> complies with it. There is no mandatory use of length as input. It is 
> certainly allowed but not mandated. And when allowing it, it is 
> accommodated via the equivalent of the 'info' ​
> ​ field:
> /"different input data strings (e.g. Label || 0x00 || Context || [L]2) 
> shall be used for different executions".
> /Length is an example and not even listed in the explicit examples at 
> the top of page 19.

You missed:

> The compromise of the keying material output from one of the 
> executions of the KDF must not degrade the security of any of the 
> keying material output from the other executions of the KDF,

Two calls to the KDF that are designed to produce the same key material 
with the same exact characteristics is fine.  But when you can call the 
KDF multiple times with the same input data and assign the output key 
stream to different lengths of keys, you have a problem.

I can do what I said - call and compromise the single byte generation of 
a key with the same input master key and INFO, and repeat it with 
increasing lengths to extract the entire key stream. I think that counts 
as cross compromise.

Later, Mike

---

From: Watson Ladd <[email-masked]>
Date: Sun, 26 Apr 2015 17:23:51 -0700

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

But the context told you what key I wanted, and how I was going to use it.
Why is that easier to enforce then one time use? I'm also not sure why we
want to protect non cert keys in an HSM: the attacker can always use the
HSM to decrypt.

>
> If I define the TLS KDF as HKDF with a context consisting of (from my now
> 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).

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 20:29:57 -0400

On 4/26/2015 4:20 PM, Hugo Krawczyk wrote:
>
>     Given SP800-108 and SP800-56C were published before your paper 
>     and the RFC and have pretty much identical math (except as I
>     noted), why shouldn't we use those cites instead of the RFC?  E.g.
>     is there any cryptographic improvement in RFC5869 vs the other two?
>
>
> ​ SP 800-108 is a framework and set of recommendations, not a 
> specific, unique KDF function. HKDF follows this framework and NIST 
> found this sufficiently important to document this in a separate 
> document SP 800-56C (which explicitly includes HKDF as an instantiation)​
> ​ .​

You didn't actually answer the base question of "is there any 
cryptographic improvement...."?

With respect to the above, SP800-56C says to use one of the SP800-108 
expansions.

Third paragraph of section 4 of SP800-56C:
> The key expansion step uses the key derivation key KDK and other 
> information exchanged and/or pre-shared, such as identifiers for the 
> involved parties, protocol identifiers, and the labels of the derived 
> keys, as the input to an approved key derivation function specified in 
> SP 800-108 [4] to produce secret keying material KM of a desired length L.

What I think you're referring to is (last paragraph of the same section):
> IETF RFC 5869 [10] describes an instantiation of the above 
> extraction-then-expansion key derivation procedure using HMAC for the 
> extraction and expansion steps. For extensive rationale on the key 
> derivation through the extraction-then-expansion procedure specified 
> in this Recommendation see [11].

But that appears to be a reference to base material rather than an 
endorsement of it as an approved function.

Cryptographically, there isn't any difference I can see except the L term.

If I were to do this I would say in TLS:

"The TLS KDF is the extraction function specified in SP800-56C combined 
with the "KDF in Feedback Mode" mode (Section 5.1) of SP800-108 with the 
following specifications:  For SP800-56C, the shall be no salt and the 
extraction function shall be as appropriate for the selected TLS PRF.  
For SP800-108, the KDF PRF shall be the MAC function of the selected TLS 
PRF with a default of HMAC-SHA256. The L and i terms shall be expressed 
as network byte order 32 bit unsigned integers.  The Label shall be the 
defined TLS label expressed as ASCII bytes, and the Context shall be the 
context defined for that specific Label encoded as per normal TLS rules. 
The ordering of the terms processed by the PRF in step 4a is as 
indicated in SP800-108 section 5.1."

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 26 Apr 2015 20:59:20 -0400

On 4/26/2015 8:23 PM, Watson Ladd wrote:
>
> > 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.
> >
>
> But the context told you what key I wanted, and how I was going to use 
> it. Why is that easier to enforce then one time use? I'm also not sure 
> why we want to protect non cert keys in an HSM: the attacker can 
> always use the HSM to decrypt.
>

This is a good question from a different direction.

In general, HSMs don't do "one time use" except as buried inside 
compound functions (e.g. the fake key pair inside an ECDSA signature).  
And it may be difficult to ensure the key is zeroized before an attacker 
can use it.    I'd rather not depend on ephemeralness as I expect 
different HSM implementations to deal with that differently.   Doing it 
by getting the derivation process correct stands a better chance of 
getting good implementations in HSMs.

In the current model, the context says how the user wants to use the 
key, but it doesn't constrain the HSM to use it that way or even to 
constrain it to produce a specific type and length of key - those are 
user inputs.  And in TLS1.2 and before the master_secret is used 
multiple times.

To the HSM, current TLS context is opaque unstructured data that gets 
mixed in without affecting the key stream to key assignment process.

With respect to protecting non-cert keys:  think about extracting the 
master secret and using steganography to hide it inside a picture on 
non-encrypted side of the server (or even the encrypted side if publicly 
available).  An attacker can retrieve that, capture the traffic stream 
externally, derive the session keys and capture the traffic safely 
remote without the betraying large amount of stolen data wandering past 
the server interface.  The attack can even forge data in the stream.  
This is obviously a made up example, but it was the first way I thought 
of using this - but consider that if an attacker can extract the master 
secret he can send it off to someone who can read the stream externally 
either in real time or later.

Later, Mike

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 27 Apr 2015 06:06:02 +0000

>attacker can't extract TLS keys.

Stepping back a bit in order to actually see the woods here, why is this an
issue?  Anyone who's using hardware for performance reasons will offload
everything to an SSL terminator, almost everyone else who doesn't want to do
that will do the crypto on the host, those worried about private-key security
will store the server key in an HSM but not do the bulk crypto there because
doing it on the host is typically much faster, and even if you do use PKCS #11
to do your bulk crypto for TLS, any attacker who's in a position to extract
the session keys from an HSM via a PKCS #11 mechanism has to control the host
it's talking to, in which case they've got direct access to the plaintext
anyway.

I realise that it's always possible to invent some scenario in which this is
an issue, but how much of a real-world impact does it actually have?  Bob
Relyea suggested TLS 1.2 PRF mechanisms in 2007 on the old Cryptoki list (and
it seemed his motivation for that was the need to be able to support it in
Mozilla's softoken implementation, for which he needed a defined PKCS #11
mechanism), and OASIS is just getting around to finalising the standard for
them now, seven years later.  This would seem to indicate that the actual
industry demand for this (not the hypothesised need but the real-world demand)
is a giant who-cares.

So as I've already said earlier in this discussion, create the best mechanism
that's a combination of good crypto design principles and ease of
implementation/deployment for existing implementations, and if someone
specifically wants to do it in an HSM they'll have to accept that they're the
odd corner case and deal with it.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 27 Apr 2015 11:22:25 +0000

> Stepping back a bit in order to actually see the woods here, why is this an issue?

+1.  I skipped quoting, but the whole message is a good one.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Michael StJohns <[email-masked]>
Date: Mon, 27 Apr 2015 13:18:02 -0400

> odd corner case and deal with it.

All of these are fair points - but miss the point that only small 
changes to what we do in TLS will permit securing all of the key 
material in the HSM and will not add to the cost of a software 
implementation.  Whereas, if you don't do anything, (or you do things 
like generating IVs as secret material), then the only choice is for the 
HSM to implement a highly specific TLS crypto system and mark keys as 
only for use in TLS.  Even then, I can't see how to reconcile security 
between that and the need for exporters given the current definitions.

With respect to TLS1.2 PRF et al in PKCS11 - imputing the delay in 
adding TLS1.2 to the spec to a general lack of a desire to do this in 
hardware is probably at best only partially correct.  A more correct 
assignment of blame is probably due to the small uptake of TLS1.2 
deployments.  See 
https://jve.linuxwall.info/blog/index.php?post/TLS_Survey  - I'm not 
sure how valid the methodology is, but that's 33% in January 2014 and 
apparently a lot less in 2010 - see page 37 of 
http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf. I 
have this suspicion that Heartbleed is at least a substantial driver for 
the increase.

Currently (TLS1.2 and before), generic HSMs can protect the server key 
pair and, once inserted in the HSM, the session keys.  What they can't 
protect are the steps between.  That's an artifact of:  use of the same 
key for both MAC and key expansion and pseudorandom bit generation (e.g. 
Initial IV and Session Nonce generation); the lack of cryptographic 
binding between the length and type of the output keys and the key 
stream generation in the key expansion formation.

In any event, there's something of a chicken and egg problem. People 
don't implement TLS using hardware because the hardware doesn't exist.  
HSM vendors don't implement TLS (or only implement PKCS11's definition 
of TLS) because the user base isn't there.  Both wait for the other.  
That also applies between versions - finding a good implementation of 
TLS1.2 was dependent on there being a market for it and that market took 
a while to develop as TLS1.0 and 1.1 were working fine for the generic 
customer (until they weren't....).

Finally, someone somewhere has figured out that they don't need to break 
into a system and steal the plain text if they can just get the system 
to send it the keys as they generate them.    I have no idea if anyone 
has accomplished such attack successfully, but it's one that bothers me 
because of how hard it might be to detect and ultimately protect 
against.  The only real defense against such an attack is a security 
module hardened against over the air attacks - hardening the system only 
gets you so far.

I've pushed hard on this because if it isn't fixed in TLS1.3, it will be 
at least 10 years to the next deployment iteration.  It seems silly to 
do something that can't be secured if it's relatively easy to do 
something that can be secured.

Later, Mike

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 28 Apr 2015 01:48:35 -0400

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 <[email-masked]>
wrote:

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Apr 2015 09:34:25 +0300

> the length of the required key. In non-HSM implementations the software

I think some proposals also had key usage for derived key as an input.

Some examples of possible usages:
- KDF input key (e.g. handshake master secret)
- AES-GCM key
- AES-CCM key
- AES-CCM8 key
- Chacha20-Poly1305 key
- HMAC-SHA256 key (MAC-only key)
- Initial IV (you have other exportables anyway)
- Exportable octet string (e.g. the unique output)

This doesn't look too difficult to add (e.g. just stick as two first
octets of info or something).

-Ilari