[tialaramex]

This is about Google's QUIC ("gQUIC") and is based on a version from 2018. It explains in the Related Work section at the end that the IETF QUIC protocol has different properties.

The trade discussed between keeping information for longer to make everything faster versus throwing it away frequently to avert tracking is _everywhere_ already. It's in your HTTP/1.1 web browser's Cookie behaviour, it's in the TLS implementation's resumption feature.

One piece of good news is that in the quest to speed things up putting the public keys into DNS means it's no longer practical to (as is discussed as a potential attack in this paper) give each client different keys so you can identify them that way. Because DNS is cache-based everybody receiving the same version of the cached data will see the same keys. This isn't a problem for good guys, everything works, but if your goal was to track people against their will it's a problem.

[ivanblagdan]

They also state that IETF QUIC proposals don’t seem to cover all aspects like abuse of the source-address token.

To my understanding, the more various identifiers you can muster, the more effective you are at identity stitching across data sets, resulting higher fidelity profiles. Are we at that point already where we’re ok at just waving off at another way to track what we do online?

Meanwhile, it seems theres already an implementation out there that covers ~7% of web traffic and is subject to this behavior. It’s been implemented single handedly by a company thats saying standards are moving too slow for it, far too often these days. That company also conveniently has a lot of stakes in the tracking game.

[zamadatix]

Putting the keys over DNS seems really clever. With DoH are requests bundled in a single session or is the session stood up and torn down per? I assume it's the former or this proposal wouldn't have gotten far but I've never actually bothered to check that far into DoH.

[tialaramex]

A DNS query wrapped as HTTP actually makes a canonically good example of a safe TLS 1.3 0-RTT transaction so in principle you don't need to keep sessions alive.

In your first (1-RTT) DNS lookup you agree a PSK (a secret key) with the DNS via DoH server.

On the next DNS via DoH lookup you send only one message, it goes like this:

Hi, it's me again. (The rest of the message is encrypted using the PSK). Here's a freshness check. I want to ask AAAA? www.google.com and also let's agree a new key for the next time I do this. Thanks, bye.

The DoH server will probably reply like this:

Hi. (The entire rest of the message is encrypted using the PSK). Here's proof I'm still me passing your freshness check. AAAA www.google.com answer is some:ipv6:address and yes, here is a new PSK for next time.

This is the same number of messages back and forth as with traditional UDP DNS albeit the messages are a little bit bigger now, and so it incurs the same latency.

Because this is 0-RTT the DoH server can't always be sure if it has seen your query before (doing this is trivial in a toy system with e.g. one DoH server on a Linux box but hard at scale with a distributed system). So a bad guy could replay the query. But, it's just a DNS query so replaying it doesn't achieve anything useful, and this doesn't help the bad guy learn anything about the query, they don't get to find out what it said or what the answer means.

[ Edited to remove mis-remembered DH for resumption, alas TLS 1.3 resumption PSKs are not forward secret ]

[fulafel]

Proposals of putting keys in DNS has a long history in IETF protocol development, it was always (?) shot down.

It was also the basis of deploying ubiquitous end2end IPsec on the internet, attempted by FreeSwan.