How do treat CID changes before HANDSHAKE_DONE

[Christian Huitema <[e-mail]>]

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