Subject: Re: [quicwg/base-drafts] Add retry integrity tag (#3120)

From: Jana Iyengar <[email-masked]>
Date: Thu, 16 Jan 2020 21:36:04 -0800

Merged #3120 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3120#event-2956965238

---

From: Christian Huitema <[email-masked]>
Date: Sat, 18 Jan 2020 18:06:30 -0800

On 1/16/2020 7:35 PM, Jana Iyengar wrote:

> Merged #3120 <https://github.com/quicwg/base-drafts/pull/3120> into
> master.
>

I am busy implementing that, and I have a doubt.

In the TLS spec, AEAD keys and vectors are derived from a master secret.
Something like:

   [sender <https://tools.ietf.org/html/rfc8446#ref-sender>]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
   [sender <https://tools.ietf.org/html/rfc8446#ref-sender>]_write_iv  = HKDF-Expand-Label(Secret, "iv", "", iv_length)

Then we use the sequence number as a "per packet nonce", and encrypt
using "IV^per-packet_nonce"

But the text of the TLS draft says "The secret key, K, is 128 bits equal
to 0xf5ed4642e0e4c8d878bbbc8a828821c9. The nonce, N, is 96 bits all set
to zero."

Should I read that as equivalent to:

    retry_key = 0xf5ed4642e0e4c8d878bbbc8a828821c9

    retry_iv = 0x00000000000000000000000000

    per-packet-nonce= 0x00000000000000000000000000

Or is it:

     retry_key = HKDF-Expand-Label( 0xf5ed4642e0e4c8d878bbbc8a828821c9,
"key", "", 16)

    retry_iv = HKDF-Expand-Label(0xf5ed4642e0e4c8d878bbbc8a828821c9,
"iv", "", 12)

    per-packet-nonce= 0x00000000000000000000000000

-- Christian Huitema

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3120#issuecomment-575957972

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 18 Jan 2020 18:14:01 -0800

I'd argue that it is the former. The new text refers to RFC5116 (AES-GCM) directly, and that's natural, because we are hardcoding the use of AES-GCM in this particular case, and because, unlike Initial packets, there is no reason to have a generalized design here.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3120#issuecomment-575958384

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 18 Jan 2020 18:19:58 -0800

PS. Though I understand your concern that not every TLS stack exposes direct access to AES-GCM.

If it is the case that the API we can assume our TLS stack to provide is a function that takes (AEAD algorithm, hash algorithm, secret, label prefix) as the input, then we should better specify those rather than specifying the AES key and IV directly.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3120#issuecomment-575958772