From a "privacy against companies like Google perspective", QUIC does not have a good track record so far with respect to its use for HTTP. The prioritisation of censorship resistence is evident in its design however a similar prioritisation for resistance to personal data collection and tracking by companies associated with online advertising, such as Google, is not.

https://www.theregister.com/2021/01/30/quic_fingerprinting_f...

https://arxiv.org/pdf/2101.11871

(Non-substantive) discussion: https://news.ycombinator.com/item?id=25969886

As an avid TLS1.3 (with ESNI for all Cloudflare sites) user, I noticed QUIC did not try to avoid sending a hostname in plain text over the wire. They could have, but they did not. There is also the issue of unnecessary HTTP headers such as User-Agent. I filter out unnecessary header in a forward TCP/HTTP proxy. How would one do this if using QUIC.

Privacy issues of ISPs in the modern web

"This is the case of QUIC, designed by Google and implemented in Google Chrome, Android smartphones as well as on Google Web servers. It relies on UDP and provides authentication and confidentiality for HTTP transactions. Nevertheless, the server hostname is transmitted in clear, posing the same privacy issues of TLS. Moreover, QUIC transmits clients User-Agent in clear, unveiling users device type."

https://core.ac.uk/download/pdf/234919911.pdf

Anyway, the potential for tracking was evident early on.

A QUIC Look at Web Tracking
Proceedings on Privacy Enhancing Technologies ; 2019 (3):255266

"Our analysis reveals that the protocol design contains violations of privacy best practices through which a tracker can passively and uniquely identify clients across several connections. This tracking mechanisms can achieve reduced delays and bandwidth requirements compared to conventional browser fingerprinting or HTTP cookies. This allows them to be applied in resource- or time-constrained scenarios such as real-time biddings in online advertising."

https://petsymposium.org/2019/files/papers/issue3/popets-201...

The efforts being made to reduce that potential have been unconvincing.

This is not the padding you are looking for! On the ineffectiveness of QUIC PADDING against website fingerprinting

"To provide protection against traffic analysis [. . . ], the working group behind QUIC, the next transport layer standard for the Web, introduced a PADDING frame in the specification [11]. In this work, we demonstrate that defenses solely based on padding QUIC traffic are ineffective against WF attacks."

https://eprint.iacr.org/2015/582.pdf

Now, years later we are presented with the proposition of using QUIC for DNS.

From the Section 7 of RFC 9250 that is the subject of this HN submission:

"The recommendation for TLS 1.3 [RFC8446] is that the capability to use 0-RTT data should be turned off by default and only enabled if the user clearly understands the associated risks. In the case of DoQ, allowing 0-RTT data provides significant performance gains, and there is a concern that a recommendation to not use it would simply be ignored."

The authors of this RFC 9250 claim they refuse to recommend turning off 0-RTT by default because (a) 0-RTT and session resumption provide performance gains and (b) they speculate any such recommendation would be ignored. Neither are adequate justifications. The problem with (a) as a justification is that the tradeoff is not simply between performance and privacy it is between privacy and commercial gain. The later can be achieved by subjugating user privacy in order to perform data collection and tracking to support the commercial interests of companies that profit from the proliferation of online advertising. The problem with (b) as a justification is that 1. it is pure speculation (in fact, there is evidence to the contrary - see below) and 2. the same speculation is not applied to Section 4.5. How does a user verify that a server is following Section 4.5.

Even if we give the RFC authors our absolute blind faith trust that they have DNS user privacy interests as their top priority, it is still clear that they are prioritising performance gains over privacy risks. It stands to reason that they would be motivated to do so because the only legitimate way DoQ can win adoption over the (less risky) alternatives is if it offers better performance.

One to Rule them All? A First Look at DNS over QUIC
https://doi.org/10.1007/978-3-030-98785-5_2

"Finally, none of the DoQ-verified resolvers offer support for QUIC 0-RTT. However, the lack of 0-RTT support might be a deliberate choice, as the use of 0-RTT exposes clients to privacy risks."

[The authors recently tested 1,217 DoQ-verified resolvers found on the internet in January 2022.]

https://arxiv.org/pdf/2202.02987