[quicwg/base-drafts] Clients cannot abandon Initial packets while server can still send initial close (#2541)

[mjoras <[e-mail]>]

17.2.2.1 of the spec current reads:
"**A client stops both sending and processing Initial packets when it sends its first Handshake packet.** A server stops sending and processing Initial packets when it receives its first Handshake packet. Though packets might still be in flight or awaiting acknowledgment, no further Initial packets need to be exchanged beyond this point. Initial packet protection keys are discarded (see Section 4.10 of [QUIC-TLS]) along with any loss recovery and congestion control state (see Sections 5.3.1.2 and 6.9 of [QUIC-RECOVERY])."

I believe this is inconsistent with section 10.3, regarding sending an initial connection close:
"If the connection has been successfully established, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. **If the endpoint does not have Handshake keys, or it is not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames in an Initial packet.** If multiple packets are sent, they can be coalesced (see Section 12.2) to facilitate retransmission."

The client may have started sending handshake packets at the point which the server decides to send a close. Since the server does not know if the client has the handshake keys it MAY send the close in an initial packet. However since the client stops (though it is missing a MUST or MAY qualifier) processing initial packets it will never process the close from the server.

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