Subject: [quicwg/base-drafts] It is unclear if some frames are forbidden in 0-RTT (#3430)

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Feb 2020 01:07:23 -0800

In TLS draft, we state that _all other frame types MUST only be sent in the 0-RTT and 1-RTT levels_, then state that it is impossible to send some of those frames in 0-RTT (HANDSHAKE_DONE, NEW_TOKEN, PATH_RESPONSE, RETIRE_CONNECTION_ID).

As it seems that we think use of these frames in 0-RTT to be forbidden, I think we should be clear about 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/issues/3430

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Feb 2020 02:20:01 -0800

See also #3435.

-- 
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/3430#issuecomment-582833566

---

From: ekr <[email-masked]>
Date: Thu, 06 Feb 2020 02:33:44 -0800

It seemed to me that the principle MT was espousing was that we don't forbid any frames in 0-RTT and just note in the draft the frames where some other rule made it impossible to send a conformant frame in 0-RTT. 

-- 
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/3430#issuecomment-582839341

---

From: Mike Bishop <[email-masked]>
Date: Thu, 06 Feb 2020 02:45:11 -0800

It's not forbidden, it's impossible -- or more precisely, it's a protocol violation to send them for other reasons.  HANDSHAKE_DONE and NEW_TOKEN frames are sent only by servers, and servers don't send 0-RTT.  A client sending them at any time is forbidden.

PATH_RESPONSE is sent only in response to a PATH_CHALLENGE; PATH_CHALLENGE can only be sent in 0-RTT or 1-RTT, and servers don't send 0-RTT.  Therefore, the client can't be responding to a PATH_CHALLENGE while it's still sending 0-RTT.

RETIRE_CONNECTION_ID can't retire the CID of its own packet.  Until the transport parameters have been parsed, the client only has one CID for the server, so it's illegal to retire it.  Once the transport parameters have been parsed, in the "simple" handshake flow, the client shouldn't be sending 0-RTT.  If the handshake requires an extra round-trip, is it possible to keep sending 0-RTT after having processed the Server Hello?

-- 
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/3430#issuecomment-582844237

---

From: ekr <[email-masked]>
Date: Thu, 06 Feb 2020 02:51:01 -0800

@MikeBishop yes, I think that is what I was saying.

-- 
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/3430#issuecomment-582846772

---

From: Marten Seemann <[email-masked]>
Date: Thu, 06 Feb 2020 06:26:46 -0800

> It's not forbidden, it's impossible -- or more precisely, it's a protocol violation to send them for other reasons.

Does that mean I can't send a FRAME_PARSING error? That would complicate things quite a bit, since I'd have to build extra tracking logic e.g. for a HANDSHAKE_DONE that is not sent in 1-RTT.

-- 
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/3430#issuecomment-582929626

---

From: Martin Thomson <[email-masked]>
Date: Thu, 06 Feb 2020 07:13:35 -0800

Why bother?  The client can't send HANDSHAKE_DONE, so you only need to check the role of the endpoint when receiving it.

-- 
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/3430#issuecomment-582951542

---

From: Mike Bishop <[email-masked]>
Date: Fri, 21 Feb 2020 12:07:51 -0800

I think you need both pieces of logic anyway.  If a peer sends HANDSHAKE_DONE in a Handshake frame, that's an error regardless of role.  You need to check the packet type on receipt.  If a client sends HANDSHAKE_DONE, that's an error regardless of packet type.  You need to check the peer's role on receipt.

The assertion here is that we don't need to expand the packet type check to overlap with the role check.  Then we get into discussion about which of multiple overlapping errors you should use.  We've done that already.

-- 
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/3430#issuecomment-589815129