Re: [quicwg/base-drafts] Remove the explicit packet number gap in favor of one computed (#496)

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.

I like this, it removes bytes on the wire at the cost of a few hashes.  Let's change the encoding for the packet later.  I agree that packing 255 new connection IDs in a single frame probably makes more sense now that you don't have an explicit gap.  A length-prefixed list is always smaller for N>1, especially since you can share the sequence number.

However, if we are going to do #460 or #20, then we might also need some way to include an updated verifier for the public reset.  That's going to create less incentive to send enough new connection IDs and the simpler frame might be easier in that case.

Let's see what others think.

>  between two points of network attachment.
 
-The NEW_CONNECTION_ID message includes a connection ID that the client can use
-for packets on the current connection.  This message also includes packet number
-gap, which is the number of packet numbers that the client skips when using the
-new connection ID.  Without this, the packet number field in the header might be
-used to link activity across networks.  A server MUST provide a 32-bit value for
-the packet number gap field that is indistinguishable from random to a passive
-observer.
+A client which wishes to break linkability upon changing networks MUST
+use the NEW_CONNECTION_ID as well as incrementing the packet sequence

`MUST use the NEW_CONNECTION_ID` implies sending, it's the value from the message that the client uses.

I'm not sure about the MUST-requirement.  Isn't this a simple "can"?

> @@ -1296,6 +1291,22 @@ connection ID, it should expect packets on the new connection ID to start at 18.
 A packet with the new connection ID and a packet number of 17 is discarded as
 being in error.
 
+#### Packet Number Gap
+
+In order to avoid linkage, the packet number gap MUST be externally
+indistinguishable from random. The packet number gap for a connection
+ID with sequence number is computed by encoding the sequence number
+as a 32-bit integer in big-endian format, and then computing:

Since packet numbers are 64-bit, might as well make this the same type.  HKDF won't care.

-- 
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/496#pullrequestreview-36152313