The packet number gap specification needs work

[huitema]

I spent some time reading the spec of the "packet gap", the random offset applied to a packet number after migrating to a new connection ID. The gap is specified in 7.7.1.1 as:

Gap = HKDF-Expand-Label(packet_number_secret,
                        "QUIC packet sequence gap", sequence, 4)

The formula relies on a "packet number secret" derived from the master secret. At first, this seems a bit complicated -- why not just a packet number? The answer of course is that often only the lower 32 bits of the packet sequence number will be transmitted in the header, the higher 32 bits have to be guessed, and if it was just a 32 bit random offset the higher 32 bits would be guessed wrong half the time. And even if the spec mandated only a 31 bit random offset, the guessing would still be wrong half the time if the client migrated twice in a row. OK. So the complexity is justified. But then there are still three valid criticisms: spec is unclear; algorithm does not actually achieve privacy; and all that would not be necessary if the packet sequence number was encrypted.

The current text is hard to follow, due to the use of "sequence number" for both the packet sequence number and the "number of the chosen connection ID in the sequence of new connection ID". I had to read it multiple times to decipher what was actually requested. I would suggest using a more precise moniker than "sequence" to designate the sequence of the connection ID. Maybe "migration sequence".

Then, the algorithm does not achieve privacy. It is unclear from the text if the server also applies the gap, or not. But if it does apply the gap, it will be the same gap as the client, and adversaries can find that to link the old and the new context. And if it does not apply the gap, then adversaries can also link the old and new context. I would suggest that the spec specifies a different computation method for the server side gap, maybe something like:

Gap = HKDF-Expand-Label(packet_number_secret,
                        "QUIC packet sequence gap", sequence^0xFFFFFFFF, 4)

Finally, let's observe that all this shifting and offsetting of the packet sequence number would not be necessary if that number was encrypted. Encryption would allow use of a single sequence number on multiple paths without compromising privacy, and that would make the transition to multipath easier.

[ianswett]

This would be closed by Stream ID encryption #1079