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

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jan 2018 15:54:05 -0800

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

---

From: hardie <[email-masked]>
Date: Thu, 11 Jan 2018 20:35:46 +0000 (UTC)

On Wed, Jan 10, 2018 at 3:54 PM, Martin Thomson <[email-masked]>
wrote:

>
>    -
>
>    during a key update, a zero-length or fixed connection ID will need
> difficulty picking the right keys.
>
If I remember correctly, one of the use cases for using a new connection ID
was when shifting the client's network attachment.  Since the shift from
using no connection ID to using a connection ID is visible to an observer
pretty trivially via the Omit Connection ID Flag:, the advice to turn them
on when connection ID shifts are occurring seems to risk that becoming a
"Yo, network change coming soon" signal.  That might make it possible to
correlate new flows to old flows just based on timing, rather than relying
on packet number gaps.

Can we tweak the advice to avoid that, or am misunderstanding the risk here?

Ted

> This is already a problem of
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1048>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5GQRX4kFFNngJxLE2pcWDNlCJZ9qks5tJU2bgaJpZM4RaHuO>
> .
>

-- 
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#issuecomment-357053314

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jan 2018 04:17:24 +0000 (UTC)

@hardie, as it turned out, the draft already addressed that point.  It strongly recommends the use of a connection ID if the client intends to break linkability:

> A client which wishes to break linkability upon changing networks MUST use the
  connection ID provided by the server.  

I didn't make any changes on this point in the PR, other than the removal of mentions of packet numbers from that specific sentence.  The point about using connection ID could be reinforced, but I think that this is sufficient to understand the trade-offs.

-- 
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#issuecomment-357849614

---

From: hardie <[email-masked]>
Date: Tue, 16 Jan 2018 10:38:33 -0800

On Mon, Jan 15, 2018 at 8:17 PM, Martin Thomson <[email-masked]>
wrote:

> @hardie <https://github.com/hardie>, as it turned out, the draft already
> addressed that point. It strongly recommends the use of a connection ID if
> the client intends to break linkability:
>
> I didn't make any changes on this point in the PR, other than the removal
> of mentions of packet numbers from that specific sentence. The point about
> using connection ID could be reinforced, but I think that this is
> sufficient to understand the trade-offs.
>
>
> Sorry for not being clear, but I don't think that as currently stated this
breaks the timing linkage.  For that, it would have to say something like
"MUST consistently use connection IDs" as well.

My concern is that shifting from the "omitting connection ID" state to the
"sending connection ID" state could be a signal of imminent connection
change.  If you can observe all flows going to a destination,
cross-correlating the new flows that show up after this signal with those
that disappear after this signal seems to provide a potential link.  It's
not perfect, of course, but there are traffic patterns where I think it
would be real.

If you think this is well understood outside the document, I'm willing to
forgo this change, but I don't think the document itself is clear on this
yet.

> —
> You are receiving this because you were mentioned.
> <https://github.com/quicwg/base-drafts/issues/1048#issuecomment-357849614>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5EI_BNSeP74-AcFVciJjcrTAaA2gks5tLCLSgaJpZM4RaHuO>
> .
>

-- 
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#issuecomment-358062107

---

From: Martin Thomson <[email-masked]>
Date: Tue, 16 Jan 2018 23:38:24 +0000 (UTC)

OK, I understood the signal, but misread the translation into specific actions.  Yes, consistent use is necessary or you create "correlate me!" signals.  I'll amend the text.  Essentially, I think that we're going to have to say that an endpoint that expects to ever need to migrate will have to send connection ID always.

-- 
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#issuecomment-358144551