Re: Alternate Version + Salt in Alt-Svc

[Tommy Pauly <[e-mail]>]

I do think that this privacy concern is a valid issue to think about and try to mitigate, or at least reduce in scope. Good to discuss!

Clients could of course choose to not use a version received via Alt-Svc when they don't want to be linked (in which case they would also not want to do 0-RTT, etc). So there could be guidance on when to use these versions. That may reduce the amount that the alternate version gets used, though; and even end up causing failures only of some categories of connections.

Another way out here is to use the Alt-Svc value that comes from another source, like the proposal in HTTPSSVC. That would be harder to target users with.

Best,
Tommy

> On Nov 4, 2019, at 12:34 PM, Ryan Hamilton <rch=[e-mail]> wrote:
> 
> Howdy Folks,
> 
> We've discussed the idea of attempting to reduce ossification by allowing the server to deliver an alternative version and initial salt to the client which can be used to speak "QUIC v1". One such mechanism for delivering this version to the client is Alt-Svc. In the context of HTTP/3 this has the wonderful property that even the first connection from a client to the server can use this alternative version.
> 
> However, it seems that there might be a privacy/linkability issue with this approach that I'm curious to get the groups' take on. If this information were delivered via Alt-Svc, I would imagine that the naïve implementation would be to cache the Alt-Svc info as until it expires (via the ma= attribute) and use the alternative version/salt in each subsequent QUIC connection. Since the version field is 32 bits, that potentially allows each user to use a distinct version. This is great for anti-ossification, but seems problematic for linkability/privacy.
> 
> I can think of solutions/mitigations for this issue (like restricting the number of bits which can be flipped by the server, or expiring the alternative version in the client on first use, etc) but I'd be curious if this seems like an issue to other folks first.
> 
> Cheers,
> 
> Ryan