Re: [quicwg/base-drafts] CONNECTION_CLOSE in Handshake too (#3293)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -2481,12 +2481,15 @@ have 1-RTT keys, so the endpoint SHOULD send CONNECTION_CLOSE frames in a
 Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD send
 CONNECTION_CLOSE frames in an Initial packet.
 
-A client will always know whether the server has Handshake keys
-(see {{discard-initial}}), but it is possible that a server does not know
-whether the client has Handshake keys.  Under these circumstances, a server
-SHOULD send a CONNECTION_CLOSE frame in both Handshake and Initial packets
-to ensure that at least one of them is processable by the client.  These
-packets can be coalesced into a single UDP datagram (see {{packet-coalesce}}).
+A client will always know whether the server has Handshake keys (see
+{{discard-initial}}), but it is possible that a server does not know whether the
+client has Handshake keys.  Under these circumstances, a server SHOULD send a
+CONNECTION_CLOSE frame in both Handshake and Initial packets to ensure that at
+least one of them is processable by the client.  Similarly, a peer might be

To ensure that there is a record of this.  There are situations where handshake keys are available for sending, but not receiving at both peers.

The client might have sent it's last Handshake packet, but the server can't read 1-RTT until it processes that packet (and maybe verifies a certificate).  A server might have sent its first Handshake flight, but the client hasn't received all of it, so it won't have 1-RTT keys.

-- 
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/pull/3293#discussion_r356361750