Subject: [quicwg/base-drafts] Define Context and Length inputs to HKDF-Expand-Label (#4571)

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Jan 2021 21:38:21 -0800

This was a pretty serious omission, even if it was obvious enough that no one ever noticed when implementing it.

Closes #4489.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4571

-- Commit Summary --

  * Define Context and Length inputs to HKDF-Expand-Label

-- File Changes --

    M draft-ietf-quic-tls.md (14)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4571.patch
https://github.com/quicwg/base-drafts/pull/4571.diff

-- 
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/4571

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Jan 2021 22:11:33 -0800

@kazuho commented on this pull request.

Thank you for working on this. I have one concern.

> @@ -937,6 +941,12 @@ Initialization Vector (IV); see {{aead}}.  The header protection key uses the
 "quic hp" label; see {{header-protect}}.  Using these labels provides key
 separation between QUIC and TLS; see {{key-diversity}}.
 
+Both "quic key" and "quic hp" are used to produce keys, so the Length provided
+to HKDF-Expand-Label along with these labels is determined by the size of keys
+in the AEAD or header protection algorithm. The Length provided with "quic iv"
+is the length of the AEAD nonce, specifically N_MAX, though the value of N_MIN
+is the same for the AEAD algorithms that can be used; see {{!AEAD}}.

I had assumed that we are using the nonce length specified in [RFC 8446 section 5.3](https://tools.ietf.org/html/rfc8446#section-5.3). As the proposed text mentions, the results for the cipher suites being defined are the same, but the definition in RFC 8446 is that the nonce length is `min(8, N_MIN)`. I do not think there is a reason to deviate from TLS 1.3 and think that we should delegate the definition of nonce length to RFC 8446.

-- 
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/4571#pullrequestreview-562346842

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 16:31:55 -0800

@martinthomson commented on this pull request.

I'm OK with this being independent of RFC 8446.  Though I've changed to N_MIN (no sense in being different).  We can deal with the problem of `N_MIN < 8` if that ever happens (such an AEAD might not be suitable for use with QUIC.

-- 
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/4571#discussion_r553037315

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 16:32:09 -0800

@martinthomson pushed 1 commit.

e1d596a0055c13d85e41777e0934190b7a150c74  Switch to N_MIN

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4571/files/32061951eb08fa84252d69690963fceb26a640c7..e1d596a0055c13d85e41777e0934190b7a150c74

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Jan 2021 17:52:39 -0800

Thank you for the changes. It's better, but IMO `max(8, N_MIN)` is preferable than `N_MIN`.

The reasons are:
* I'm not sure if we need to allow N_MIN < 8 (should that happen), considering the fact that our packet numbers are 62 bits.
* From implementation perspective, it would be better if we can be clear that QUIC would not change the size of the nonce of cipher suites that are defined by TLS 1.3.

Though I can concede with current state of PR, because QUIC cannot silently add support for new cipher suites as they get defined for TLS. We need to define header protection for each of them, so we can delegate the discussion of AEAD nonce size.

-- 
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/4571#discussion_r553064443

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 22:51:43 -0800

So that was my rationale: no one can sneak in an AEAD with `N_MIN < 8`.   At that point we can deal with it.  One way we might decide to deal with it is to limit the maximum packet number to `256^N_MIN`, assuming we really want that AEAD.

-- 
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/4571#discussion_r553139882

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Jan 2021 23:01:40 -0800

@martinthomson
> no one can sneak in an AEAD with `N_MIN < 8`

I think the correct argument is "no one can sneak in an AEAD with `N_MAX < 8`"? RFC 8446 states that (which I think is correct), and to support cipher suites that are `N_MIN < 8 && N_MAX >= 8`, it says that the AEAD nonce size is `max(N_MIN, 8)`.

I think it's perfectly reasonable for us to follow that.

-- 
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/4571#discussion_r553142920

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 23:17:39 -0800

dff7c81de71c9e2a33b416086522784610eabca9  Kazuho convinced me.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4571/files/e1d596a0055c13d85e41777e0934190b7a150c74..dff7c81de71c9e2a33b416086522784610eabca9

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 23:17:57 -0800

OK, that's good enough for me.  I don't like it, but the "can't sneak one in" still applies.

-- 
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/4571#discussion_r553148468

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Jan 2021 23:21:16 -0800

@kazuho approved this pull request.

-- 
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/4571#pullrequestreview-563258001

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Jan 2021 23:21:30 -0800

Merged #4571 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/4571#event-4178544191