Subject: [quicwg/base-drafts] Allow application CONNECTION_CLOSE everywhere (#3446)

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Feb 2020 00:31:40 -0800

In fixing #3435, I realized that it was tricky to send an application-level close in 0-RTT because of the need to potentially send a close in Initial or Handshake packets. However, the same applies to 0.5-RTT. The client might not have 1-RTT keys when the server sends a CONNECTION_CLOSE in a short header packet.

Rather than try to remap application errors onto transport errors to solve this, just let the application signal an error any time.  Sure, both 0-RTT and 0.5-RTT both have in common the lack of input from a peer, so signaling an error seems unnecessary, but the restriction we have only exists because we aren't sure that the condition is valid. But it might be. Imagine that an application error condition could be triggered by TLS extensions or transport parameters. Or maybe the endpoint just doesn't want to continue.

Lifting the restriction should simplify a lot of things.

-- 
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/3446

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 10 Feb 2020 01:23:46 -0800

I am not sure if that is the correct thing to do.

IIRC, the reason we have limited use of application CONNECTION_CLOSE to 1-RTT is because the error code is part of the application protocol, and because the role of QUIC as a transport protocol is to provide "encryption" to the application protocol. That's what we agreed late last year, see #3158.

The flip side of allowing application close to be sent using Initial packets is that every application protocol using QUIC would be required to specify the error codes that can be sent using Initial packets or not, because the error code sent using an Initial packet would be observable.

I would argue that *that* would be a complexity.

-- 
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/3446#issuecomment-584029218

---

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

That is an entirely reasonable objection.  The question then becomes: what do we do when we have a desire to signal an application-level error, but we aren't sure that the peer can receive a packet that is amply protected?

For instance, if a server accepts 0-RTT only to find that the contents are gibberish, it might signal in a 1-RTT packet with the appropriate application CONNECTION_CLOSE, but it has no guarantee that this will be readable to a client.

I suspect that the right answer is to switch to a transport-level CONNECTION_CLOSE with a different error code in that case.

Allowing application CONNECTION_CLOSE in 0-RTT would still make sense then, if only to keep the API surface consistent.

-- 
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/3446#issuecomment-585563461

---

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

> I suspect that the right answer is to switch to a transport-level CONNECTION_CLOSE with a different error code in that case.

Agreed. FWIW, we state the following, which I think is the right advice.
_When an application wishes to abandon a connection during the handshake, an endpoint can send a CONNECTION_CLOSE frame (type 0x1c) with an error code of 0x15a ("user_canceled" alert; see [TLS13]) in an Initial or a Handshake packet. ([section 19.19](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-19.19-7))_

> Allowing application CONNECTION_CLOSE in 0-RTT would still make sense then, if only to keep the API surface consistent.

No objection from 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/3446#issuecomment-585567516

---

From: Nick Banks <[email-masked]>
Date: Thu, 13 Feb 2020 06:48:34 -0800

I agree with @kazuho. Just use the CONNECTION_CLOSE frame with the generic user_canceled TLS alert.

-- 
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/3446#issuecomment-585792040