Re: Removing packet number gaps

[Martin Thomson <[e-mail]>]

PR here: https://github.com/quicwg/base-drafts/pull/1043

On Tue, Jan 2, 2018 at 12:57 PM, Martin Thomson
<[e-mail]> wrote:
> 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.