>
> This is why that I suggested (but it may be a bad idea, may be I
> didn't think of everything) that a privacy-conscious client may be
> better by not using connection migration, and resetting to an entirely
> new connection when the IP address changes.
You cannot do that for non-trivial protocols such as HTTP because you need
application state that cannot be interrupted during migration. Even if you
create a new connection, the server would still need to know how to connect the
new connection to the existing state. You might for example be in the middle of
transferring a picture over an HTTP stream when migrating. You would have to
drop the picture and restart transfer at the new connection. And it wouldn’t be
hard for the server to fingerprint.
You could imagine other more privacy conscious protocols, also over QUIC, but
you would have to define your own application protocol, and explicitly disallow
connection migration and possibly also 0-RTT. For example, you could create a
public FTP like service in this way and restart file download if connection is
broken due to user migration. QUIC has a 0 connection ID that disallows
migration, so you can do this if you want.
QUIC discussions has mostly focused on the HTTP use case, and general TCP
replacement, for version 1, although I and others have also pushed for other
use cases such as symmetric server to server communication.
If you really want privacy you can do more than QUIC does, such as onion
routing, but that might depend on middleware and require trust to be placed
elsewhere. This presumably comes at a cost of latency and complexity which is
outside the design scope of QUIC.
You might also want to look into QUIC tunnelling, but I have not studied this
in detail.
