RE: Removing packet number gaps

[Marcus Ihlar <[e-mail]>]

+1
Consecutive packet numbers are important for spin bit observers.

/Marcus
-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Roni Even (A)
Sent: den 2 januari 2018 07:12
To: Lubashev, Igor <[e-mail]>; Martin Thomson <[e-mail]>; QUIC WG <[e-mail]>
Subject: RE: Removing packet number gaps

+1
Roni

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Lubashev, Igor
Sent: Tuesday, January 02, 2018 4:15 AM
To: Martin Thomson; QUIC WG
Subject: RE: Removing packet number gaps

Could we use PLUS instead of XOR?  My understanding is that there is little cryptographic difference between XOR and PLUS, and it is nicer to have consecutive packet numbers on the wire...

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]]
Sent: Monday, January 01, 2018 8:57 PM
To: QUIC WG <[e-mail]>
Subject: Removing packet number gaps

There are number of problems with packet number gaps that I think we need to address.  Most are minor.  For instance, the initial packet number is not close to zero, which inflates the size of ACK frames from the very beginning of a connection.

However, Christian just identified one that I think makes this more important to address: when using a new connection ID, the gap is the same size on both client and server.  This makes flows linkable.  The gaps between the last packet on the old flow and the first packet on the new flow can be calculated in both directions.  Flows can be linked by finding flows where client-to-server packets have the same (or very close) gaps as server-to-client packets.

With a few small tweaks to the current design, I think that we get a much better solution.  Here is what I propose:

Firstly, packet numbers start at zero and always increase monotonically, with no gaps.  A side benefit of this is that the first ACK frame will have a small encoding for largest_acknowledged (1 octet rather than 8 in most cases).

Packet numbers are never encoded directly onto the wire, they are XORed with a masking value.  This value will change for different packet protection keys, and for different connection IDs.  Client and server will use different values so that gaps are hard to detect.

Thus, we will have a third key derivation:

   key = QHKDF-Expand(S, "key", key_length)
   iv  = QHKDF-Expand(S, "iv", iv_length)
   pnmask = QHKDF-Expand(S, "pnmask", 4)

To make this work seamlessly, I'm proposing a tweak to QHKDF-Expand that includes the connection ID.  For that, the "Context" field that we currently do not use seems like a good choice.

This will mean changes to the other uses of QHKDF-Expand:

* the handshake secret can be changed to be a fixed rather than a derived value, so that we don't need to use the function (connection ID will be added during expansion into the separate keys)

* during a key update, a zero-length or fixed connection ID will need to be used so that there is no confusion about which connection ID was in use at the time the update was made (editorially, I'm not certain how to manage this one, I might just go back to using HKDF-Expand-Label directly for that)

Finally, we need to be very clear that even if the connection ID is omitted, those packets still use the implied connection ID in key derivation.  We will probably want to recommend that endpoints include a connection ID if they intend to support NEW_CONNECTION_ID or any of the related functions, at least around the time when a connection ID change is in place or the recipient of their packets could have difficulty picking the right keys.  This is already a problem of course, but this change would make it worse.