User tracking has been discussed a lot during the development of the QUIC protocol. That is not say the discussion is no longer relevant, but it has not been ignored.
For servers, it is necessary to track users across migrations, because you need to maintain connection state and to maintain the IP address of where to send data. One could add meta-criteria outside the protocol such as the QUIC application must not extract IP data or other user identifiable data from the stack, but that is not enforceable within the protocol, and it is also not always desirable. For example when having to whitelist users. On the other hand it is important to not allow servers to track users across different connections. This is complicated because of 0-RTT state being maintained. I think perhaps more work could be done in this area for future versions. On the other hand there is wording in the protocol to prevent external observers from linking different connections to the same user, although it may still be possible through traffic analysis which is also mentioned as a limitation, if I remember correctly. Mikkel > On 7 Jun 2021, at 15.04, Stephane Bortzmeyer <[email protected]> wrote: > > On Mon, Jun 07, 2021 at 01:52:19PM +0100, > Lucas Pardue <[email protected]> wrote > a message of 43 lines which said: > >> As Robin says, to survive such client IP changes would require QUIC >> connection migration. RFC 9000 Section 9.5 [1] deals with the privacy >> implications of migration. > > This section is completely silent about tracking BY THE SERVER. It > only considers a passive observer, which is not the only threat. >
