Subject: [TLS] PR#875: Additional Derive-Secret Stage

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Feb 2017 13:15:52 -0800

I've just posted a pull request which slightly adjusts the structure of key
derivation.
PR#875 adds another Derive-Secret stage to the left side of the key ladder
between each pair of HKDF-Extracts. There are two reasons for this:

- Address a potential issue raised by Trevor Perrin where an attacker
  somehow forces the IKM value to match the label value for Derive-Secret,
  in which case the output of HKDF-Extract would match the derived secret.
  This doesn't seem like it should be possible for any of the DH variants
  we are using, and it's not clear that it would lead to any concrete
  attack, but in the interest of cleanliness, it seemed good to address.

- Restore Extract/Expand parity which gives us some flexibility in
  case we want to replace HKDF.

I don't expect this change to be controversial and I'll merge it on Monday
unless I hear objections.

Thanks,
-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Feb 2017 10:46:13 +1100

This is a good idea.

>   attack, but in the interest of cleanliness, it seemed good to address.

Just to highlight this point: if we need to add a PQ key exchange,
there is no guarantee that it will have exactly the same properties as
the key exchange methods we have today.  I expect that need to arise
relatively soon, so that's an extra good reason to make this change.

---

From: John Schanck <[email-masked]>
Date: Fri, 10 Feb 2017 11:04:33 -0500

> This is a good idea.

+1

> relatively soon, so that's an extra good reason to make this change.

For the same reason, I think the labels for these new Derive-Secret
calls should anticipate extensions that provide additional input
secrets.

This PR specifies labels for the PSK and (EC)DHE inputs

  Derive-Secret(., "derived early secret", "")
  Derive-Secret(., "derived handshake secret", ""),

but the draft seems to allow arbitrarily many input secrets. Just above
the diagram it says

"Given a set of n InputSecrets, the final "master secret" is computed
 by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2,
 etc."

So we might want the labels in the new Derive-Secret calls to indicate
which InputSecret is being incorporated, e.g.

  Derive-Secret(., "derived secret 1", "")
  Derive-Secret(., "derived secret 2", "")
  Derive-Secret(., "derived secret 3", "")
  etc.

I should also note that the draft does not specify how an extension
would produce an additional input secret. So, alternatively, we could
just strike out the "Given a set of n InputSecrets" line.

I personally think there should be a way for extensions to provide
additional input secrets. I can submit a PR along those lines if
there is interest.

-John

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 22 Feb 2017 15:03:41 -0500

On Thu, Feb 9, 2017 at 4:15 PM, Eric Rescorla <[email-masked]> wrote:

> I've just posted a pull request which slightly adjusts the structure of
> key derivation.

​I want to stress, also as advise for future uses of HKDF, that a
recommended practice for HKDF is to always follow HKDF-extract with
HKDF-expand. That's how HKDF is defined and departing from it should be
done with utmost care. The issue raised by Trevor is an example of such
subtleties. In particular, note that HKDF-Extract does not carry a "info"
input while HKDF-Expand does, and such field is almost always essential for
key separation and to tie derived keys to some particular context.

Hugo

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