Subject: [quicwg/base-drafts] Allow CONNECTION_CLOSE in 0-RTT (#3435)

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

The exception for CONNECTION_CLOSE in 0-RTT is just odd.  We currently exclude things from 0-RTT only because they are impossible.

As @marten-seemann says, "feel free to send me a PROTOCOL_VIOLATION when I send CONNECTION_CLOSE 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/3435

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 06 Feb 2020 02:29:50 -0800

IIRC, the rationale behind forbidding use of CONNECTION_CLOSE in a 0-RTT packet was that the client should send CONNECTION_CLOSE in an Initial or Handshake packet. I am fine with allowing use of CONNECTION_CLOSE in 0-RTT, as long as that advice is kept (or stated).

-- 
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/3435#issuecomment-582837639

---

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

After sending CONNECTION_CLOSE, the client is supposed to enter the draining state and stop sending other than to repeat the connection close.  However, the server might reject 0-RTT, in which case the server doesn't know the connection has been closed.  I see the principle for including it, but I agree with @kazuho that we should advise clients that it's kinder to send the CONNECTION_CLOSE at other encryption levels as well / instead to ensure the server can read 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/3435#issuecomment-582839013

---

From: ianswett <[email-masked]>
Date: Thu, 06 Feb 2020 02:54:08 -0800

There's already text about sending connection close in the highest encryption level the sender knows the peer can process.  When 0-RTT is sent, the client doesn't know whether the server can process the packets.

See text starting with
 "When sending CONNECTION_CLOSE, the goal is to ensure that the peer
   will process the frame.  Generally, this means sending the frame in a
   packet with the highest level of packet protection to avoid the
   packet being discarded."
in https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-10.3

I think the existing text advises clients not do this, but making it illegal is silly.

-- 
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/3435#issuecomment-582848085

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Feb 2020 20:39:34 -0800

The testing of that feature is going to be interesting. Besides the case of servers that just don't negotiate 0-RTT because they don't feel like it today, there is also the case of 0-RTT packets being lost. The loss is not guaranteed to be detected before the TLS handshake complete. A bad faith server could just ignore any 0-RTT packet that carries a connection close request, and do as if it was not received. I get the desire of treating 0-RTT just like 1-RTT, but the number of corner cases is going to be fun.

-- 
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/3435#issuecomment-585546726

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Feb 2020 21:40:03 -0800

Let's be clear: we have a problem of this shape already.  A server can sent CONNECTION_CLOSE prior to confirming that the client has the keys necessary to interpret it.  It might even have good cause to do so.

Ignoring signals is always possible; these signals exist largely as a courtesy, so that endpoints don't dedicate resources to connections their peer no longer wants.

-- 
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/3435#issuecomment-585560815

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 12 Feb 2020 22:13:13 -0800

To add to what @martinthomson has pointed out, the server possibly ignoring frames contained in 0-RTT packet is not limited to CONNECTION_CLOSE.

While I have a mixed feeling about allowing most if not all 1-RTT frames in 0-RTT too, it is my understanding that that has been the principle we have agreed. I would very much prefer applying the principle everywhere rather than making decisions on a case-by-case basis.

-- 
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/3435#issuecomment-585568906