Allow CONNECTION_CLOSE in 0-RTT

[martinthomson]

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".

[kazuho]

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).

[MikeBishop]

After sending CONNECTION_CLOSE, the client is supposed to enter the closing state and stops responding 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.

[ianswett]

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.

[huitema]

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.

[martinthomson]

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.

[kazuho]

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.