Subject: [quicwg/base-drafts] Are both types of CONNECTION_CLOSE frames permitted during the handshake? (#3713)

From: Rui Paulo <[email-masked]>
Date: Tue, 02 Jun 2020 15:51:50 -0700

I think the spec is ambiguous when it says in section 17.2:

> PING, PADDING, and CONNECTION_CLOSE frames are also permitted. An endpoint that receives an Initial packet containing other frames can either discard the packet as spurious or treat it as a connection error.

and:

>Handshake packets MAY contain CONNECTION_CLOSE frames.

But CONNECTION_CLOSE can mean 0x1c or 0x1d.  Are both permitted during the 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/3713

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 02 Jun 2020 16:06:20 -0700

@rpaulo: In this case, the intent is to allow both. Unless explicitly specified, I would read the text to mean both types of CONNECTION_CLOSE frames.

-- 
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/3713#issuecomment-637852947

---

From: Rui Paulo <[email-masked]>
Date: Tue, 02 Jun 2020 16:08:59 -0700

Okay, if more people think that way, we can close with no action.

-- 
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/3713#issuecomment-637853745

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 02 Jun 2020 16:52:00 -0700

The question is directly addressed in the TLS specification. It says _CONNECTION_CLOSE frames signaling errors at the QUIC layer (type 0x1c) MAY appear in any packet number space. CONNECTION_CLOSE frames signaling application errors (type 0x1d) MUST only appear in the application data packet number space._ (https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#section-4-4.2).

This was the outcome of several issues that we discussed recently, #3440 was the fix that we applied.

I agree that there is ambiguity in the transport draft and that we'd better have an editorial refinement.

-- 
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/3713#issuecomment-637869668

---

From: Martin Thomson <[email-masked]>
Date: Tue, 02 Jun 2020 16:51:54 -0700

So on the surface, there is no inconsistency: the two sections permit CONNECTION_CLOSE.

But the question about the different types of CONNECTION_CLOSE is more relevant than @janaiyengar's response might imply.  We currently require that CONNECTION_CLOSE of type 0x1d (application close) is not sent in Initial or Handshake packets.  So that's a drafting error, and we might reasonably take this as an editorial issue.

However, if the question is about what a reaction to receiving an application CONNECTION_CLOSE in one of those packets, we might consider a different posture.

If you get an application CONNECTION_CLOSE in an Initial packet that is otherwise valid, you probably want to drop the connection.  And you probably don't want to start sending CONNECTION_CLOSE in response every time, because that leads to madness.  But this is a general problem: if you detect and error and that error keeps being repeated, it probably isn't a good idea to generate a CONNECTION_CLOSE in response to every infraction.

-- 
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/3713#issuecomment-637869572

---

From: Martin Thomson <[email-masked]>
Date: Tue, 02 Jun 2020 23:37:49 -0700

I'm going to re-close the can of worms I half-opened in my earlier comment and take this as editorial.

>From memory, the larger question of how to deal with junk is something we've discussed several times.  If anyone wants to take that up, I'm happy to do that, but let's at least correct the obvious error.

-- 
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/3713#issuecomment-637988729

---

From: Rui Paulo <[email-masked]>
Date: Wed, 03 Jun 2020 10:53:57 -0700

It does make sense that we only allow 0x1c during the 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/3713#issuecomment-638361408

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 03 Jun 2020 13:27:32 -0700

@rpaulo : Apologies, I misspoke -- I was speaking to interpretation of text, rather than the actual question itself.

-- 
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/3713#issuecomment-638443296

---

From: Martin Thomson <[email-masked]>
Date: Thu, 04 Jun 2020 04:00:10 -0700

Closed #3713 via #3714.

-- 
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/3713#event-3406302999