Re: [quicwg/base-drafts] Rework Retry packet (#1498)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -568,9 +568,11 @@ Packet Number, and Payload fields.  These are replaced with:
 
 ODCIL:
 
-: The length of the Original Destination Connection ID field as an unsigned
-  8-bit integer.  This field does not use the same encoding as the DCIL and SCIL
-  fields.
+: The length of the Original Destination Connection ID field.  The length is
+  encoded in the least significant bit of the octet using the same encoding as

Needs more than one bit.

> +
+A server MUST only send a Retry in response to a client Initial packet.
+
+If the Original Destination Connection ID field does not match the Destination
+Connection ID from most recent the Initial packet it sent, clients MUST discard
+the packet.  This prevents an off-path attacker from injecting a Retry packet
+with a bogus new Source Connection ID.
+
+The client responds to a Retry packet with Initial packet that includes the
+provided Retry Token to continue connection establishment.
+
+A server that might send another Retry packet in response to a subsequent
+Initial packet MUST set the Source Connection ID to new value of at least 8
+octets in length.  This allows clients to distinguish between Retry packets when
+the server sends multiple rounds of Retry packets.  A server that will not send
+additional Retry packets can set the Source Connection ID to any value.

But it's already rejecting a ODCID that doesn't match what it picked, and it has to have picked something >= 8 bytes, no?

> @@ -731,12 +733,18 @@ If the client has a token received in a NEW_TOKEN frame on a previous connection
 to what it believes to be the same server, it can include that value in the
 Token field of its Initial packet.
 
-A client SHOULD NOT reuse a token.  Reusing a token on different network paths
-would allow activity to be linked between paths (see {{migration-linkability}}).
-A client MUST NOT reuse a token if it believes that its point of network
-attachment has changed; that is, if there is a change in its local IP address or
-network interface.  A client needs to start the connection process over if it
-migrates prior to completing the handshake.
+A token allows a server to correlate activity between connections.
+Specifically, the connection where the token was issued, and any connection
+where it is used.  Clients that want to break continuity of identity with a
+server MAY discard tokens provided using the NEW_TOKEN frame.  Tokens obtained
+in Retry packets MUST NOT be discarded.

The prohibition below is on using a token on two different network paths.  But since the token is likely to contain address validation information, should we recommend against using the token from a different address than the one where it was received?  Or is that solely a risk of server tracking and it's covered in the privacy-from-server paragraph here?

-- 
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/1498#pullrequestreview-136404800