Re: A question about user tracking with QUIC

[Christian Huitema <[e-mail]>]

On 6/7/2021 7:51 PM, Spencer Dawkins at IETF wrote:
> This all seems very reasonable to me. The other question is about timing -
> how urgent do people think this guidance is?
I am not sure about that. The most urgent issue is the tracking via TLS 
session tickets, but that's exactly the same issue as TLS over TCP, it 
has been known for ages, and I am confident that browser developers are 
well aware of it. So the sky is not exactly falling.
>
> Christian characterized "if you don't want to be tracked when you migrate,
> you probably shouldn't migrate" as a classic mitigation, and I'm also
> wondering if we still have the classic level of concern about traceability.
> If our level of concern has been increasing, that might make things more
> urgent. But as you said, it's good for us to encourage other people to
> express an opinion.

Well, yes, but if instead of migrating the client starts a new session 
using a different IP address and use a session resumption ticket to 
speed up the process, it has not accomplished much. Same issue, if the 
client starts a new session using a different IP address and immediately 
identifies itself by entering a password or providing a cookie. So there 
is a bit of triage to be done between the cases. In the "logged on" 
case, the client is not in a position to avoid tracking. It could just 
as well migrate and enjoy the lower latency. But then, is there much 
real use of migration outside of "long connections in which the client 
has logged on the server?"

Then there is the NAT rebinding case. The client does not voluntarily 
migrate, and the server just observes the packets coming from a new 
address. Too late to hide that, not much point in closing the session in 
the name of privacy.

If clients really want to achieve address privacy and hide their 
location from a server on which they are often logged for long sessions, 
I think they should use a proxy or a VPN. Maybe we should discuss the 
trade-off of that too. And the various javascript APIs that surveillance 
scripts can use to ping servers outside the VPN and do some kind of 
triangulation. I hear that the Web RTC API have a rich surface for that.

All that can become very confusing very quickly, which is why I think 
there is value in teasing out the scenarios and the various trade-offs.

-- Christian Huitema