Subject: [quicwg/base-drafts] tls: EndOfEarlyData in Initial/Handshake/1-RTT (#4410)

From: Kazu Yamamoto <[email-masked]>
Date: Tue, 24 Nov 2020 20:31:11 -0800

Sec 4.5 says:

> Clients MUST NOT send the EndOfEarlyData message. A server MUST treat receipt of a CRYPTO frame in a 0-RTT packet as a connection error of type PROTOCOL_VIOLATION.

This does not specify how a server MUST do if `EndOfEarlyData` in Initial/Handshake/1-RTT is received. I think that a server MUST send the TLS alert of `unexpected_message`.

-- 
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/issues/4410

---

From: Marten Seemann <[email-masked]>
Date: Tue, 24 Nov 2020 20:44:00 -0800

Sounds reasonable to me.

-- 
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/issues/4410#issuecomment-733460255

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 25 Nov 2020 00:16:11 -0800

I'm not sure if we need to change, or if the proposed change is reasonable.

Doesn't RFC 8446 already state that the receiver MUST error-close the connection when it receives EndOfEarlyData in other epochs? Assuming that that is the case, I think that the current text is correct, because the section talks about "QUIC-Specific Adjustments to the TLS Handshake."

-- 
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/issues/4410#issuecomment-733542564

---

From: Kazu Yamamoto <[email-masked]>
Date: Wed, 25 Nov 2020 01:04:05 -0800

The draft also says:

> 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.

What is the difference between KeyUpdate and 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/issues/4410#issuecomment-733567868

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 25 Nov 2020 02:07:27 -0800

@kazu-yamamoto I'd argue that the only way to interpret that text is that the KeyUpdate message cannot be used _even when permitted by TLS 1.3_ (i.e. in 1-RTT packets). The italic part is implied, rather than explicitly stated like the case for EndOfEarlyData.

If there's ambiguity, we can try to be explicit. I do not have a strong opinion on if we need to.

-- 
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/issues/4410#issuecomment-733606521

---

From: Kazu Yamamoto <[email-masked]>
Date: Wed, 25 Nov 2020 03:02:33 -0800

To let readers interpret the text as "cannot be used", we should simply use "cannot be used". If "MUST NOT" is used, the handling should be specified.

-- 
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/issues/4410#issuecomment-733636306

---

From: kjsisco <[email-masked]>
Date: Sun, 29 Nov 2020 10:55:01 -0800

I do not think anything should change personally.

-- 
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/issues/4410#issuecomment-735438508

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 29 Nov 2020 17:38:52 -0800

FWIW I've filed #4412 that does not do anything regarding the original issue, but makes changes to the specification regarding KeyUpdate to clarify that it is not intended to respecify how TLS rejects that message during handshake.

-- 
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/issues/4410#issuecomment-735498511