Subject: [TLS] Issue 555: Generate IVs in one HKDF invocation?

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 15:09:51 -0700

Issue:
  https://github.com/tlswg/tls13-spec/issues/555

ADL suggested that we could slightly reduce the number of HKDF
computations by generating the IVs as a single block rather than
with individual HKDF-Expands. You can't generally do this kind
of slice-and-dice and preserve the key boundary, but IVs are
public anyway.

At least for NSS, this makes things slightly more complicated
because we generate the directional traffic keys independently,
but it's also not a big deal to change if people want.

Comments in favor or against?

---

From: David Benjamin <[email-masked]>
Date: Wed, 17 Aug 2016 22:52:43 +0000

In general one has to generate the directional traffic keys independently
due to read/write epochs changing at different times, so I'd prefer it left
as is. (In BoringSSL, we also generate the directional keys independently.
I'd often wished that TLS 1.2 was the same.)

The switch from handshake to traffic_secret_0 happens at different points
because the key change happens immediately after Finished on both sides
(this is important otherwise a server alert on bad client certificate is
unreadable). From traffic_secret_N to traffic_secret_N+1 is similarly
asymmetric because of KeyUpdate skew.

Not that it's a huge deal either way.

David

On Wed, Aug 17, 2016 at 6:10 PM Eric Rescorla <[email-masked]> wrote:

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

---

From: Brian Smith <[email-masked]>
Date: Wed, 17 Aug 2016 13:08:41 -1000

> of slice-and-dice and preserve the key boundary, but IVs are

When you say "IV," what are you referring to? Definitely the original
intent of my proposal to use client_write_iv and server_write_iv is
that they would remain secret. I suspect that some analysis might be
simplified by assuming that they are publicly-known as a worst-case
scenerio, but that's different than them being "public", and we should
design things assuming that we're trying to keep them private.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Aug 2016 16:47:48 -0700

> design things assuming that we're trying to keep them private.

Sorry, that's bad writing on my part. I meant they should be kept private
but
that in practice, PKCS#11 and similar implementations almost certainly don't
have support for TLS 1.3-style AES-GCM and therefore you'll have to let
the IV out of the tamper boundary at least for the foreseeable future.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Aug 2016 08:24:07 +0300

> of slice-and-dice and preserve the key boundary, but IVs are

Except that actually usefully make IVs public (without it just being
pointless disclosure), you would need MRAE, which is strictly stronger
notion that AE(AD) required by TLS. Neither GCM nor Poly1305 are
MRAE (and I don't think CCM is either).

Basically, doing generic encryption with AEAD is not possible. One
needs protocol-specific knowledge. This is because of the disaster
that repeating nonce is. TLS 1.3 protocol-level prevention of
duplicate nonces does not help any here.

> but it's also not a big deal to change if people want.

And yes, this makes code that generates the directions independently
(which is reasonable thing to do even for simple implementation)
quite much more annoying, as one needs to slice the IV buffer.

I don't also expect this to improve performance any: The code
will probably still generate directions independently, not saving
the other half of the IV, so it needs to be recomputed when the
other direction is computed. 

So complicates code for no actual benefit.

-Ilari