Re: A question about user tracking with QUIC

[Christian Huitema <[e-mail]>]

I think Stéphane raises an interesting point: QUIC does enable 
trade-offs between privacy and performance, and these trade-offs are not 
well documented in the published RFC. The main trade-off comes from the 
use of session resumption, including 0-RTT. A similar trade-off results 
from using retry tokens provided in NEW TOKEN frames. A secondary 
trade-off comes from the use of connection migration.

Session resumption in QUIC uses the mechanisms described in TLS 1.3. The 
risks is actually documented in RFC 9001, in section 9.1 of the session 
considerations, "Session Linkability". The entire text says: "Use of TLS 
session tickets allows servers and possibly other entities to correlate 
connections made by the same client; see Section 4.5 for details." 
Section 4.5 is the description of the resumption mechanism. The relevant 
text in that section says: "Session resumption allows servers to link 
activity on the original connection with the resumed connection, which 
might be a privacy issue for clients. Clients can choose not to enable 
resumption to avoid creating this correlation. Clients SHOULD NOT reuse 
tickets as that allows entities other than the server to correlate 
connections; see Appendix C.4 
<https://www.rfc-editor.org/rfc/rfc8446#appendix-C.4> of [TLS13 
<https://www.rfc-editor.org/rfc/rfc9001.html#TLS13>]."
<https://www.rfc-editor.org/rfc/rfc9001.html#name-session-linkability>

The session resumption risk is not new to QUIC. This is exactly the same 
issue as resumption of a TCP/TLS session. QUIC does add an additional 
tracking mechanism with the "NEW TOKEN", which is designed to bypass 
source address verification and save one RTT by showing a proof that the 
IP address was already verified. This token could certainly allow some 
form of tracking. We can debate whether this is an additional risk 
compared to the TLS session token, but Stéphane's point hold: this 
trade-off between performance and privacy is not analyzed and documented.

Similarly, there are potential trade-offs with the support of connection 
migration. A client that attempts migration reveals the new IP address 
used for that migration. A client that acts on a "server preferred 
address" parameter may end up using and revealing a new IP address. We 
can argue that the trade-offs are OK, but they are just that, 
trade-off.And they are indeed not documented in the RFC.

There are mitigations to all these risks. For example, the classic 
mitigation for session resumption privacy risk is for the client to not 
use it at all, or to only use it if the IP address did not change and if 
the ticket was provided recently. The same apply for the "NEW TOKEN" 
variants of retry tokens. It is actually hard for clients behind NAT to 
know that their IP address did not change, so such mitigations need 
work. Similarly, there is a worthwhile discussion of migration risks, 
which are different if the client identifies itself to the server at the 
application layer and if it doesn't. It might be a very good idea to 
publish that.

-- Christian Huitema

On 6/7/2021 7:37 AM, Mikkel Fahnøe Jørgensen wrote:
> Also note that a lot of dicussions have taken place on github issues and pull requests.
>
>> On 7 Jun 2021, at 16.20, Stephane Bortzmeyer <[e-mail]> wrote:
>>
>> On Mon, Jun 07, 2021 at 03:36:31PM +0200,
>> Mikkel Fahnøe Jørgensen <[e-mail]> wrote
>> a message of 37 lines which said:
>>
>>> User tracking has been discussed a lot during the development of the
>>> QUIC protocol.
>> User tracking BY THE SERVER? I'm sure the WG left no stone unturned
>> but I cannot find this discussions in the email archives. I probably
>> used the wrong keywords.
>>
>>> 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.
>> 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.
>>