Re: [quicwg/base-drafts] Clarify server CONNECTION_CLOSE with Handshake (#2688)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -2307,10 +2307,14 @@ signal closure.
 If the connection has been successfully established, endpoints MUST send any

We should also try to kill #2151 with this change:

```suggestion
When sending CONNECTION_CLOSE, the goal is to ensure that a 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.  However, during
the handshake, it is possible that more advanced packet protection keys are not
available to a peer, so the frame MAY be replicated in a packet that uses a
lower packet protection level.

If the connection has been successfully established, endpoints MUST send any
```

> @@ -2307,10 +2307,14 @@ signal closure.
 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 {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server may not know whether the client has Handshake keys.  In order to

That assumes a lot about the shape of the handshake though.  If you are going to make that call, cite QUIC-TLS.

> @@ -2307,10 +2307,14 @@ signal closure.
 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 {{packet-coalesce}}) to facilitate retransmission.
+in a Handshake packet.  If the endpoint does not have Handshake keys, it SHOULD
+send CONNECTION_CLOSE frames in an Initial packet.
+
+The server may not know whether the client has Handshake keys.  In order to
+guarantee a CONNECTION_CLOSE is processed, it SHOULD send a CONNECTION_CLOSE
+in both Handshake and Initial, because the client discards Initial keys as soon
+as it has Handshake keys. If multiple packets are sent, they can be coalesced
+(see {{packet-coalesce}}).

A bigger point here is that the server also isn't sure when the client gets 1-RTT keys.  We should say the same about that transition.  I believe that we can rely on handshake confirmation for this transition.  Endpoints might choose to send CONNECTION_CLOSE in Handshake packets prior to the handshake being confirmed.

-- 
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/2688#pullrequestreview-236443175