Re: [quicwg/base-drafts] Application close should be disallowed in Initial or Handshake (#3158)

[Kazuho Oku <[e-mail]>]

@nibanks Thank you for checking.

> Things may be difficult in some scenarios, but we can leave the decision on how to handle things up to the application layer.

The problem is that then there would be two requirements:
* Application protocols MUST define a generic error code that can be exposed unencrypted.
* QUIC stacks need to provide an API that tells the application if a CONNECTION_CLOSE frame is going to be sent using Initial packets. Each application needs to consult that in order to determine the error code to be sent.

> For the 0-RTT scenario, you can use a generic application error code. There's no ALPN ambiguity there, right, since they have to use the same one as previous?

There is. The case is where there is an error in the 0-RTT data that the client sends, and the server responds with a CONNECTION_CLOSE frame. In this case, there is no ambiguity on the server-side, as the server has committed to processing a particular application protocol. However, there is an issue on the client-side. The client cannot tell which application protocol has been selected, as the CONNECTION_CLOSE frame (carried in either Initial or Handshake) may arrive before it receives the Encrypted Extensions handshake message that carries the name of the negotiated protocol. We *can* say that a server sending an application-level close before the client sends an 1-RTT packet is an alternative way of negotiating the protocol. But are we really going to say that? I think it's too complicated.

-- 
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/3158#issuecomment-547254865