Subject: [TLS] HKDF

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Mar 2015 09:19:59 -0500

As I mentioned in a previous message [0] during the interim we discussed
moving from the TLS PRF to HKDF [RFC5869].

The general sentiment was:

- Move to HKDF
- Specify both SHA-256 and SHA-384 (the latter being required for
  Suite B)

This is also the time when we would want to look at adjusting
the key expansion to separate keys and IVs (assuming we still
have IVs).

Please use this thread to discuss this topic.

-Ekr

[0] https://www.ietf.org/mail-archive/web/tls/current/msg15621.html

---

From: Dave Garrett <[email-masked]>
Date: Mon, 23 Mar 2015 16:15:26 -0400

> [0] https://www.ietf.org/mail-archive/web/tls/current/msg15621.html

Adding support for SHA-3 hashes seems like a good idea at this point.

There's also issue #26 [1] which proposed picking a one-true-hash. I also proposed a SHA2+SHA3 construct as a possible route, which was briefly discussed [2]. (construct TBD by CFRG) The basic premise of a combined hash in this instance is to provide a better guarantee of security if either SHA-2 or SHA-3 were to be broken.

Any of this viable at this juncture?

[1] https://github.com/tlswg/tls13-spec/issues/26
[2] https://www.ietf.org/mail-archive/web/tls/current/msg13264.html

Dave

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Mar 2015 23:58:08 -0500

> On Mar 23, 2015, at 9:19 AM, Eric Rescorla <[email-masked]> wrote:
> 

OK, since you’re proposing to abandon the current TLS PRF:

1. Why? What is wrong with the TLS PRF, and 
2. If we’re changing it, why not to a fast PRF such as blake2?

Yoav

---

From: Andrey Jivsov <[email-masked]>
Date: Mon, 23 Mar 2015 23:01:44 -0700

> 2. If we’re changing it, why not to a fast PRF such as blake2?
I am somewhat sympathetic to this sentiment. Please also consider that 
KDFs and related processes are standardized by NIST. E.g.:

1. NIST-prescribed way to do KDF, SP 800 108A (it includes HMAC KDF for 
key expansion)

2. NIST DH schemes include KDF, SP 800-56A rev2 (HKDF paper of 2010 
criticizes the first revision; rev 2 is dated 2015)

3. NIST grandfathered TLS KDF in SP 800-135.

4. A very similar SP 800-56C that documents Extraction-then-Expansion, 
where expansion is done with #1 (credits Hugo Krawczyk, among others)

Please note that at least some of these can be FIPS 140 tested (in 
particular, TLS PRF). Suite B expects the use of these approved KDFs.

While NIST is perhaps too prolific with these, I feel that we should 
look into standard KDFs. There are test vectors, verifications systems, 
existing implementations...

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Mar 2015 06:39:43 -0500

> On Mar 24, 2015, at 1:01 AM, Andrey Jivsov <[email-masked]> wrote:
> 
> I am somewhat sympathetic to this sentiment. Please also consider that KDFs and related processes are standardized by NIST. E.g.:
> 
> 1. NIST-prescribed way to do KDF, SP 800 108A (it includes HMAC KDF for key expansion)
> 
> 2. NIST DH schemes include KDF, SP 800-56A rev2 (HKDF paper of 2010 criticizes the first revision; rev 2 is dated 2015)
> 
> 4. A very similar SP 800-56C that documents Extraction-then-Expansion, where expansion is done with #1 (credits Hugo Krawczyk, among others)
> 
> Please note that at least some of these can be FIPS 140 tested (in particular, TLS PRF). Suite B expects the use of these approved KDFs.
> 
> While NIST is perhaps too prolific with these, I feel that we should look into standard KDFs. There are test vectors, verifications systems, existing implementations…

If such a KDF is needed for Suite-B, then it makes sense for Suite-B ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM.  

Why not include a different PRF in those suites that have non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever signature scheme CFRG are going to recommend?

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 24 Mar 2015 14:16:32 +0200

> Why not include a different PRF in those suites that have non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever signature scheme CFRG are going to recommend?

Or even special Suite B ciphersuites. I think there are only 2 of
those.

- ECDHE/P-256, ECDSA/P-256, AES-128-GCM, SHA-256
- ECDHE/P-384, ECDSA/P-384, AES-256-GCM, SHA-384

The basic idea being: They who care can implement that.

-Ilari

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 24 Mar 2015 13:29:15 -0400

​Here are some clarifications about HKDF that can help better understanding
its
rationale and use in (OP)TLS.

Note: all places where I say random it can (and sometimes should) be
replaced by
pseudo-random meaning indistinguishable from a uniform random string.

- HKDF is standardized by NIST (as an *approved* KDF mechanism) in
SP-800-56C
  where it is explicitly stated that HKDF complies with this standard:
  "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]." For those interested, [11] appeared in Crypto
2010
  and is here http://eprint.iacr.org/2010/264.

- HKDF uses a two-step mechanism by which one first extracts randomness
from a
  possibly non-uniform secret input to create a uniformly random string
that is
  then used with a regular PRF to generate keying material. In (OP)TLS we
denote
  the two steps as HKDF-Extract and HKDF-Expand. The rationale of the
extraction
  part is to concentrate the "secret entropy" of the input on a single
strong
  cryptographic key (from which more keys can be derived).

- HKDF uses HMAC for both extract and expand but it could use, in
principle, any
  regular PRF (including those from NIST) for expansion. Extraction is
trickier
  since it is not a generic property of PRFs. The reason to use HMAC for it
is
  that the HMAC construction has properties that support the extraction
  functionality under reasonable cryptographic assumptions.

- Skipping the extraction property would require keying a PRF with a
non-uniform
  key in which case the usual properties of PRF cannot be guaranteed as
these
  properties assume a uniform random key. In TLS with RSA this was not a
problem
  since the key transported under RSA was chosen as a random uniform string.
  When using a DH key or passphrase this is not the case.

- Beyond the important cryptographic reasons for the extraction step, this
also
  solves the problem of having to adapt the size of the secret input to
that of
  a length of the key in the PRF: for example, how do you key AES-256 with a
  point on a 512 elliptic curve? Even with a 256 curve you would require
point
  compression which you may or may not want to use (I hope this comment
does not
  open a discussion of EC point representations :-).

- The expansion function of HKDF is HMAC-based and is ESSENTIALLY THE SAME
as in
  previous TLS. It even has the same feedback mode that TLS uses to expand
a key
  (the exact inputs to the iterations changes a bit but nothing major).

- There is no need for ultimate performance in the key derivation in TLS.
These
  operations are relative minor compared to the algebraic operations.

- There is nothing that ties HKDF to OPTLS in a fundamental way other than
it
  supports the provability of the protocol, hence improving the confidence
on
  its design. In particular, it supports a clean hierarchical key
derivation for
  all the protocol modes.

Hugo
​

On Tue, Mar 24, 2015 at 8:16 AM, Ilari Liusvaara <
[email-masked]> wrote:

> existing implementations…
> >
> > If such a KDF is needed for Suite-B, then it makes sense for Suite-B
> ciphersuites - the ones with ECDSA, P-256 or P-384 for ECDHE, and AES-GCM.
> >
> > Why not include a different PRF in those suites that have
> non-NIST-approved algorithms such as ChaCha20, Curve25519, and whatever
> signature scheme CFRG are going to recommend?
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 25 Mar 2015 08:02:30 -0700

A problem with this is additional options.

There is no problem with HKDF that I see other than it relaxes assumptions
on hash functions, but we would not be using such weak hash functions in
TLS. HKDF is probably viewed as an insurance. Please note that the benefits
will be bound by the "ad-hoc" methods to process entropy into private keys.

One idea for meaningful reduction of complexity in TLS is if we could
switch to cipher-based KDF. We countinue to use hash for digital
signatures, controlled by the signature extension. An AEAD cipher is
required and has the MAC method internal to them. Therefore, this would
drop hash functions from the ciphersuites.
On Mar 24, 2015 7:16 AM, "Ilari Liusvaara" <[email-masked]>

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 25 Mar 2015 08:21:25 -0700

On Mar 25, 2015 10:02 AM, "Andrey Jivsov" <[email-masked]> wrote:

... but some people like AEAD stream ciphers.

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 25 Mar 2015 11:21:38 -0400

> A problem with this is additional options.

​What are the additional options? ​

​You use the defined hash function.

> on hash functions,
​Relaxing assumptions is not a problem but rather a good thing: It means
that you need to assume less from the hash function, e.g. not having a
scheme broken if collisions are found on that function. In some cases we
still need to model the hash function as a random oracle but we minimize
these cases and only need to assume it for the compression function not the
iterated one (the iterated function contradicts the random oracle model
just by virtue of extension attacks).
​

> but we would not be using such weak hash functions in TLS.
>
​I am not sure what you mean by this - the problem is that we never know
how weak a hash function is until we know... (i.e someone breaks it).
​

> HKDF is probably viewed as an insurance. Please note that the benefits

​That's true, but these ad-hoc methods have a better analytical basis than
just using non-uniform keys to key directly a PRF.
​

> switch to cipher-based KDF.
>
​That's for the WG to decide but the results we have for the extraction
properties of block-cipher based PRFs are much weaker.
​

> We countinue to use hash for digital signatures, controlled by the
> signature extension.
>
An AEAD cipher is required and has the MAC method internal to them.
> Therefore, this would drop hash functions from the ciphersuites.
>
 You need hash functions for generating the session hash, even if you
don't use a digital signature at all.

Hugo
​

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 25 Mar 2015 16:36:16 +0100

On Wed, 2015-03-25 at 11:21 -0400, Hugo Krawczyk wrote:

>         One idea for meaningful reduction of complexity in TLS is if
>         we could switch to cipher-based KDF. 
> ​That's for the WG to decide but the results we have for the
> extraction properties of block-cipher based PRFs are much weaker.

I'm not sure whether the WG should even decide on replacing the KDF or
the main protocols used. That was certainly a non-goal for TLS 1.3 and
is a cryptographic decision which is not the expertise of this group.
For such decisions, and even simpler (see Salsa20, ChaCha cipher
addition) this working group delegated these decisions to CFRG, and I
believe this should also be done now if we go the path of replacing
core TLS structure.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 25 Mar 2015 19:15:31 +0200

On Wed, Mar 25, 2015 at 11:21:38AM -0400, Hugo Krawczyk wrote:
> scheme broken if collisions are found on that function.

TLS 1.3 already assumes prf-hash is collision-resistant.

Changing this is incredibly hard, requiring extreme effort. You would need
incredibly broad security proofs.

> just using non-uniform keys to key directly a PRF.

I'm not seeing how you can have any sort of adversarial input fed to TLS
PRF without having much more serious problems.

Prf-hash on the other hand needs to take full burnt of adversarial input,
with no strengthening at all. ​

> properties of block-cipher based PRFs are much weaker.

Because you need a CR hash function anyway, you can't reduce complexity
that way.

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Wed, 25 Mar 2015 08:47:26 -1000

> - Specify both SHA-256 and SHA-384 (the latter being required for

Assuming that the choice of either SHA-256 or SHA-384 is fixed per
cipher suite, as is the case with TLS 1.2, switching to HKDF seems
like a good idea to me.

> the key expansion to separate keys and IVs (assuming we still

If the IVs are secret (only shared between the two peers) then I don't
see the need to change how they are calculated from the keyblock.

Cheers,
Brian

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Mar 2015 14:12:12 -0500

> see the need to change how they are calculated from the keyblock.

The issue is that in many cases the IV will be handled outside the crypto
module, and the keys should stay inside the crypto module. The traditional
slice and dice makes that hard.

-Ekr

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 25 Mar 2015 21:07:55 -0500

> the main protocols used. That was certainly a non-goal for TLS 1.3 and

​
There is an explicit goal of supporting forward secrecy and 0-RTT.
Both require changes to the protocol, in particular the latter requires
introducing server's (semi) static DH keys and an authentication mode that
cannot be solely based on signatures hence necessarily departing from
previous TLS versions. You could add support for the above elements as a
patch/addition to the protocol but even then you would need a review of the
new cryptographic elements and their interaction with the old ones (which
may be trickier to analyze than a well-formed uniform protocol).

Hugo
​

---

From: Brian Smith <[email-masked]>
Date: Wed, 25 Mar 2015 16:36:02 -1000

> slice and dice makes that hard.

When the implementation cares about this, won't it also care that the
nonce/IV is completely managed within the crypto module too?
Otherwise, for certain things like AES-GCM, the application could
attack the crypto module reusing a nonce in order to learn the key.
Using the design I suggested in [1] allows the crypto module to
completely manage the nonce/IV in a way that makes such abuse
impossible. In fact, with that design, the crypto module doesn't even
need to tell the application what the nonces/IVs are. And that can
happen without changing how the nonces are derived from the keyblock.

Conversely, if the crypto module *doesn't* work like that, then it
isn't clear to me that it is actually offering a useful amount of
protection of the key material. It doesn't seem useful to make things
more complicated in order to support that kind of design, which seems
broken.

Cheers,
Brian

[1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 26 Mar 2015 09:15:59 +0200

> may be trickier to analyze than a well-formed uniform protocol).

Well, these changes to "unify" the key exchange completely change how
to the key exchange works, and need to completely redo any security
analysis. This is nasty for multiple reasons:
a) The scope of analysis is very broad (there have been a number of
   "TLS proven secure" papers that don't prove TLS secure, due to
   insufficient scope)
b) The changes to proposed look to make it much harder to analyze,
   even if 0RTT is assumed unsupported
c) When 0RTT is added, I don't see how the changes make the interaction
   any easier to analyze.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 26 Mar 2015 09:24:40 +0200

> more complicated in order to support that kind of design, which seems

Turns out you can't even implement TLS fully in design that does not
know about TLS, nor does it seem one can even change TLS so that
would be possible (at least without introducing gaping security holes).

-Ilari

---

From: Michael StJohns <[email-masked]>
Date: Thu, 26 Mar 2015 10:51:41 -0400

> attack the crypto module reusing a nonce in order to learn the key.

Not exactly.  On the encrypt side, there's a desire that the IV/Nonce be 
produced and controlled by the crypto module, but doing that is actually 
pretty hard given the large number of different ways of forming said 
nonce proposed by different protocols and usages (e.g. compare what TLS 
is doing to what Zigbee or other IOT protocols are doing).

On the decrypt side, you *must* provide the input IV/Nonce as an input - 
it can't be generated internally for the reasons mentioned above and 
there are also issues with lost or ignored (untimely) messages (general 
crypto issue, not typically a TLS one)
> happen without changing how the nonces are derived from the keyblock.

But doing that requires that the module have yet another TLS specific 
method.

The general contract (going back to probably the first version of PKCS11 
and others) for encrypt/decrypt APIs is a per-message IV. AEAD modes 
such as CCM and GCM are trying to modify that contract to make the 
encrypt dependent on a per-session value concatenated with a per-message 
value (with a counter for the per-block part).  I'm no longer working 
with the PKCS11 folks at Oasis, but a year ago what we were looking at 
was some form of PKCS11 mechanism that might be called an IV generator.  
The set of those mechanisms was not small.

> more complicated in order to support that kind of design, which seems

My personal goal is to be able to build a crypto module that has NO TLS 
specific tweaks - where I can provide as inputs (safely in that doing 
this doesn't adversely affect security) that allow the module do TLS, 
but where doing that or allowing that doesn't prevent the module from 
doing say IPSEC, Zigbee, etc also securely.

Moving to a "standard" KDF is a good start.  Removing the first message 
IV/per-session Nonce generation from the master key expansion is even 
more helpful.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Thu, 26 Mar 2015 10:55:48 -0400

On 3/26/2015 3:24 AM, Ilari Liusvaara wrote:
> know about TLS,

This is true for TLS1.2 and before, mainly because of the master secret 
expansion and the PRF.  Everything else is bog standard crypto.

> nor does it seem one can even change TLS so that

I don't know that I believe that.  TLS is a protocol wrapped around a 
set of cryptographic constructs.  There are ways to use standard 
constructs in TLS to build a secure protocol.   It will require some 
surgery on TLS1.2, but I think that's well underway.

Mike

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 26 Mar 2015 18:44:27 +0200

On Thu, Mar 26, 2015 at 10:55:48AM -0400, Michael StJohns wrote:
> I don't know that I believe that.  TLS is a protocol wrapped around a set of
> cryptographic constructs.  There are ways to use standard constructs in TLS
> to build a secure protocol.   It will require some surgery on TLS1.2, but I
> think that's well underway.

The problem is that TLS includes values that are potentially:

- Exportable
- Channel Binding
- Secret

All at the same time. Such value needs to chain to MS, and is exportable.

-Ilari

---

From: Richard Moore <[email-masked]>
Date: Thu, 26 Mar 2015 21:46:18 +0000

> Adding support for SHA-3 hashes seems like a good idea at this point.

Since SHA-3 hasn't yet been released this isn't currently possible.

Rich.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Mar 2015 11:55:42 -0700

> think that's well underway.

It depends on what the guaranties of the crypto module are. If you
provide AES-GCM, then you need a mechanism to ensure nonces aren't
repeated, and that won't be generic.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin