Subject: [quicwg/base-drafts] handling of KeyUpdate in other epochs are specified in RFC 8446, do not override (#4412)

From: Kazuho Oku <[email-masked]>
Date: Sat, 28 Nov 2020 20:38:12 -0800

QUIC-TLS defines some &quot;adjustments&quot;(https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-quic-specific-adjustments-t) to TLS 1.3.

As they are adjustments, we are updating TLS only when necessary. However, discussion in #4410 seems to have revealed one corner case that is ambiguous. This PR addresses that problem.

To be specific, TLS 1.3 defines the necessary action when an endpoint receives KeyUpdate massage in epoch other than 1-RTT. However, current statement in QUIC-TLS can be read as if it is updating that. This PR makes it clear that the &quot;adjustment&quot; applies to only when the use of KeyUpdate is permitted by TLS 1.3 but not in QUIC-TLS.

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

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

-- Commit Summary --

  * handling of KeyUpdate in other epochs are specified in RFC 8446, do not override

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4412.patch
https://github.com/quicwg/base-drafts/pull/4412.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/4412

---

From: Marten Seemann <[email-masked]>
Date: Sat, 28 Nov 2020 20:55:20 -0800

@marten-seemann commented on this pull request.

> @@ -1426,8 +1426,8 @@ packet that contains the changed value.
 
 This mechanism replaces the TLS KeyUpdate message.  Endpoints MUST NOT send a
 TLS KeyUpdate message.  Endpoints MUST treat the receipt of a TLS KeyUpdate
-message as a connection error of type 0x10a, equivalent to a fatal TLS alert of
-unexpected_message (see {{tls-errors}}).
+message in a 1-RTT packet as a connection error of type 0x10a, equivalent to a
+fatal TLS alert of unexpected_message (see {{tls-errors}}).

IIUC, KeyUpdate is forbidden by the the TLS spec, right? Can we add a sentence here that states taht?

-- 
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/4412#pullrequestreview-540447436

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 28 Nov 2020 23:18:53 -0800

@kazuho pushed 1 commit.

b33c48762efdd88170eebed13272bc14278495a1  clarify that TLS sends KeyUpdates only in 1-RTT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4412/files/31c15369b4f27d4e0b03dfe46ca9eae22ebb8a5c..b33c48762efdd88170eebed13272bc14278495a1

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 28 Nov 2020 23:19:51 -0800

@kazuho commented on this pull request.

PTAL at b33c487. With the change, I think the text now aligns better with what we state for EOED ([section 8.3](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-removing-the-endofearlydata)).

-- 
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/4412#discussion_r532167561

---

From: Kazu Yamamoto <[email-masked]>
Date: Sun, 29 Nov 2020 21:33:47 -0800

@kazuho `h3spec` now supports an error case of TLS KeyUpdate in 1-RTT. Based on experiments with `h3spec`, it appeared that TLS stack might be freed already when any CRYPTOs including KeyUpdate in 1-RTT are received. So, we should also allow `PROTOCOL_VIOLATION` in this case.

-- 
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/4412#issuecomment-735556760

---

From: Marten Seemann <[email-masked]>
Date: Sun, 29 Nov 2020 21:38:15 -0800

I don't see any reason to specifically allow PROTOCOL_VIOLATION here (it's allowed as a fallback for any error code anyway), as it's possible for a QUIC stack to generate an error code in the CRYPTO_ERROR space, even if the TLS stack has already been shut down.

-- 
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/4412#issuecomment-735558440

---

From: Kazu Yamamoto <[email-masked]>
Date: Sun, 29 Nov 2020 21:57:00 -0800

@marten-seemann It's possible but it's not reasonable because QUIC stack needs to parse TLS messages.

BTW, where can I find the fallback rule?

-- 
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/4412#issuecomment-735565792

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 29 Nov 2020 23:18:09 -0800

@kazu-yamamoto 
> It's possible but it's not reasonable because QUIC stack needs to parse TLS messages.

A QUIC stack that discards the TLS state post-handshake is committing to handle TLS messages by itself. Therefore, it has to handle them correctly.

In practice, such QUIC stack running as clients have to handle NewSessionTicket messages correctly (therefore they need to be capable of parsing TLS messages). Such stacks running as servers can respond with unexpected_message alert for any post-handshake message because in RFC 8446 there isn't a case where a client unilaterally sends a post-handshake message with the only exception being KeyUpdate.

> BTW, where can I find the fallback rule?

It is defined at https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-11-2.

-- 
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/4412#issuecomment-735601008

---

From: Kazu Yamamoto <[email-masked]>
Date: Mon, 30 Nov 2020 00:25:22 -0800

> It is defined at https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-11-2.

Thanks. I'm fine with this rule. So, I withdraw my suggestion.

-- 
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/4412#issuecomment-735634176