Re: [quicwg/base-drafts] Change connection ID with Transport Parameters (#1041)

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.

I have a few reservations about using transport parameters for this.  I know we had some concerns about using NEW_CONNECTION_ID for this, but it might be a better approach.  I can already think of at least one gotcha with that, but it's potentially a cleaner model.

> @@ -690,14 +690,16 @@ The client MUST choose a random connection ID and use it in Initial packets
 ({{packet-initial}}) and 0-RTT packets ({{packet-protected}}).
 
 When the server receives a Initial packet and decides to proceed with the
-handshake, it chooses a new value for the connection ID and sends that in a
-Handshake packet ({{packet-handshake}}).  The server MAY choose to use the value
-that the client initially selects.
+handshake, it may chooses a new value for the connection ID and sends that in

MAY choose I think

> @@ -690,14 +690,16 @@ The client MUST choose a random connection ID and use it in Initial packets
 ({{packet-initial}}) and 0-RTT packets ({{packet-protected}}).
 
 When the server receives a Initial packet and decides to proceed with the
-handshake, it chooses a new value for the connection ID and sends that in a
-Handshake packet ({{packet-handshake}}).  The server MAY choose to use the value
-that the client initially selects.
+handshake, it may chooses a new value for the connection ID and sends that in
+the server_connection_id transport parameter ({{transport-parameter-definitions}})
+of the Handshake packet ({{packet-handshake}}).

A transport parameter can't be "of the Handshake packet".  You can drop from "of" onward.

>  
-Once the client receives the connection ID that the server has chosen, it MUST
+If the client receives a new connection ID that the server has chosen, it MUST

Transport parameters are only really available once the handshake completes.  For one, they are in TLS EncryptedExtensions, which isn't necessarily right up front.  More importantly, though we could release them before the handshake completes, it makes it harder to reason about their authenticity.  Given that transport parameters are used for client address validation, that's problematic.

>  use it for all subsequent Handshake ({{packet-handshake}}) and 1-RTT
 ({{packet-protected}}) packets but not for 0-RTT packets ({{packet-protected}}).
 
+The server MUST NOT switch to the new connection ID until has received a
+packet containing the connection ID from the client.  In particular, the

I think that it is easier to make the switch with the change to 1-RTT protected packets.  Creating another mini-protocol here complicates things considerably.  Outside of cases with packet loss (where you can't rely on the client being able to recover the transport parameters), the only real difference is that you are changing the connection ID sent with the client's second flight (it's set of Handshake packets).

Now, I agree that there is potentially some value in having the right markings on the client Handshake packets, but maybe the right answer here is to use NEW_CONNECTION_ID.

-- 
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/1041#pullrequestreview-87409147