Subject: Did the crypto change with draft-tls-14?

From: Christian Huitema <[email-masked]>
Date: Thu, 16 Aug 2018 09:57:12 -0700

Looking at the changes between draft-ietf-quic-tls-13 and
draft-ietf-quic-tls-14, I see that HKDF-Expand-Label specifications have
grown an extra empty string parameter, e.g. change from:

   client_initial_secret = HKDF-Expand-Label(initial_secret, "client
in", Hash.length)

To:

   client_initial_secret = HKDF-Expand-Label(initial_secret,
                                             "client in", "",
                                             Hash.length)

The empty string is also present in the latest TLS-13 drafts and in RFC
8446, and the spec did say that the keys "are computed in the same
fashion as the corresponding TLS keys". I assume that the change in spec
there is purely editorial, and that the existing test vector remains
valid (except for the version number). Is that correct?

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Aug 2018 10:20:05 -0700

What happened here is that the text in -13 was just wrong, because
HKDF-Expand-Label()  takes 4 arguments.

And when I changed it from QHKDF-Expand, I just forgot. So, it's an
editorial change in that -13 and -14 should have the same crypto. A
technical change in that -13 couldn't be implemented w/o this correction.

-Ekr

---

From: Rui Paulo <[email-masked]>
Date: Fri, 17 Aug 2018 11:06:36 -0700

Thanks for the explanation! I was having a hard time figuring this one out :-)

—
Rui Paulo

> On Aug 16, 2018, at 10:20, Eric Rescorla <[email-masked]> wrote:
> 
> What happened here is that the text in -13 was just wrong, because HKDF-Expand-Label()  takes 4 arguments.
> 
> And when I changed it from QHKDF-Expand, I just forgot. So, it's an editorial change in that -13 and -14 should have the same crypto. A technical change in that -13 couldn't be implemented w/o this correction..
> 
> -Ekr
> 
> 
>> On Thu, Aug 16, 2018 at 9:57 AM, Christian Huitema <[email-masked]> wrote: