[quicwg/base-drafts] Packet number rework (#1048)

[Martin Thomson <[e-mail]>]

This collates a number of issues with how we are managing packet number encoding, linkability, randomization and other things.  From the mail sent to the list:

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.

-- 
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/issues/1048