Subject: How do treat CID changes before HANDSHAKE_DONE

From: Christian Huitema <[email-masked]>
Date: Thu, 20 Feb 2020 17:10:57 -0800

In the past, we have discussed the potential benefits for the client of
quickly switching to a new connection ID once the handshake is complete.
Suppose for example that there are several connections multiplexed on
the same 5 tuple between a client and a server. Without migration,
attackers can observe the pairing between CID used in each direction of
traffic, associate a client sub-stream to a server sub-stream, and use
that for example as input in a fingerprinting mechanism. If clients and
server migrate to new CIDs, that pairing becomes more difficult. The
question is, when to start doing that? And my proposal is, "after
handshake complete", which in the client case means "after receiving
handshake done".

I have two worries. On one hand, I am concerned that staring a migration
while the handshake is not finished makes the handshake process less
robust to packet loss. On the other hand, I am also concerned that all
potential privacy benefits of migrating to new CIDs are lost if the peer
sends handshake packets with long headers associating the new DCID with
the old SCID. For example, the client may have to repeat the final
handshake packet on a timer. It will have to use a pair of CID in the
long header. If it uses the new ones, it will reveal the linkage between
the new client and server CID. If it uses the old one, it might end up
using a CID that the server already discarded after the transition. The
client can avoid these issues by simply waiting "handshake done" before
migrating to new CID.

There is some ambiguity in the spec on this subject. On one hand,
section 9 says that "An endpoint MUST NOT initiate connection migration
before the handshake is confirmed, as defined in section 4.1.2 of
[QUIC-TLS
<https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#QUIC-TLS>]."
On the other hand, section 9.5 says that "At any time, endpoints MAY
change the Destination Connection ID they send to a value that has not
been used on another path." What shall the peer do if it receive data on
a new DCID before the handshake is complete, before the handshake
encryption keys have been discarded? My simplifying assumption is that
before the handshake is done, peer can simply treat all incoming DCID as
equivalent to DCID[0], and not trigger any specific processing. Is that
correct?

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 22 Feb 2020 19:57:00 +1100

Hi Christian,

I think that perhaps you are conflating the two concepts of migration and connection ID use here, but your conclusion is absolutely correct.

Using a new connection ID does not imply migration, though migration implies use of a new connection ID.  So while a client can use new connection IDs during the handshake, it cannot move to a new path until it sees HANDSHAKE_DONE.

There are a few things implied by this.  Most relevant here is that when an endpoint issues a new connection ID, by any means, it has to be prepared to receive packets that use that connection ID.

If you think that you can see a way to improve the description of this in the draft, I'd appreciate your thoughts.

Cheers,
Martin

On Fri, Feb 21, 2020, at 12:10, Christian Huitema wrote:
> quickly switching to a new connection ID once the handshake is 
> complete. Suppose for example that there are several connections 
> multiplexed on the same 5 tuple between a client and a server. Without 
> migration, attackers can observe the pairing between CID used in each 
> direction of traffic, associate a client sub-stream to a server 
> sub-stream, and use that for example as input in a fingerprinting 
> mechanism. If clients and server migrate to new CIDs, that pairing 
> becomes more difficult. The question is, when to start doing that? And 
> my proposal is, "after handshake complete", which in the client case 
> means "after receiving handshake done".
> 
> I have two worries. On one hand, I am concerned that staring a 
> migration while the handshake is not finished makes the handshake 
> process less robust to packet loss. On the other hand, I am also 
> concerned that all potential privacy benefits of migrating to new CIDs 
> are lost if the peer sends handshake packets with long headers 
> associating the new DCID with the old SCID. For example, the client may 
> have to repeat the final handshake packet on a timer. It will have to 
> use a pair of CID in the long header. If it uses the new ones, it will 
> reveal the linkage between the new client and server CID. If it uses 
> the old one, it might end up using a CID that the server already 
> discarded after the transition. The client can avoid these issues by 
> simply waiting "handshake done" before migrating to new CID.
> 
> <https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#QUIC-TLS>]." On the other hand, section 9.5 says that "At any time, endpoints MAY change the Destination Connection ID they send to a value that has not been used on another path." What shall the peer do if it receive data on a new DCID before the handshake is complete, before the handshake encryption keys have been discarded? My simplifying assumption is that before the handshake is done, peer can simply treat all incoming DCID as equivalent to DCID[0], and not trigger any specific processing. Is that correct?
> 
> -- Christian Huitema
>