It feels like such a huge missed opportunity that QUIC is just so bad at multiplexing different concerns. I get that the limitation that DoDQ runs on port 853 is in part a feature, that separating it's network traffic is in some ways/cases desireable, but that DoDQ can't also be useful- for an operator who wants to- over port 80, is as much a limitation of QUIC's intent/design as it is a conscious design decision made by the RFC; there's not really another way to do it, short of generating some new protocol signaling system. Rather than being a raft we can tie more concerns to, QUIC is a prototype we have to keep building yet more and more ships from the skeleton of. I wish QUIC were more ambitious, aimed to encapsulate more varied concerns by it's nature, rather than leaving each protocol to fork off the core.
I keep seeing this wonderful flexible multicast new protocol (QUIC), but see these really big ways it limits what it wants to take on in really harmful ways. The unreliable datagrams spec, for example, punted entirely on multiplexing[1]. Every unreliable protocol that needs different "streams"/channels then has to go invent streams all over again, but there's no guarantee the different implementations will be compatible & able to share the one and only unreliable data-channel datagrams affords. This is easily witnessable in MASQUE[2].
Ideally I'd like to see some kind of standard for declaring protocol, so different streams of different protocols can "just work" over a shared QUIC connection. And I'd like to see streams brought to datagrams, with perhaps one shared/default "global" (per-connection) stream alike what we have now. There's so much good protocol work here, but we keep being just short of making it easy to layer things in; so close, but falling in critical areas for lack of ambition.
> Abstract: This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.
> [...] DNS over HTTPS (DoH) [RFC8484] can be used with HTTP/3 to get some of the benefits of QUIC. However, a lightweight direct mapping for DoQ can be regarded as a more natural fit for both the recursive to authoritative and zone transfer scenarios, which rarely involve intermediaries. In these scenarios, the additional overhead of HTTP is not offset by, for example, benefits of HTTP proxying and caching behavior.
Why is parallel delivery over multiple streams an issue for DNS? Is the idea to maintain a persistent connection to a DNS server and keep sending requests over that connection? That means the DNS server has a permanent connection to track your network activity, which Google would probably like.
Performance. Making every network-element, every hop, have to add something to the routing table is slow. QUIC is either 1 or 0-RTT encryption, depending on if there's existing contact (irrc), so I guess we can't argue encryption delays matter much. There's other abstract concerns though- having multiple short-lived connections in your OS and routing tables consumes resources- minimizing resource consumption is a decent goal.
I don't know how long the "connection" is expected to remain around. It could be long lived. QUIC is over UDP, and connection becomes more a QUIC concept & pattern of use than otherwise. But I don't see how this is worse than what we do now, which involves an ongoing long dialog with one or two select dns servers. I guess one could say there's some ambiguity at the moment, now, about who exactly a request is coming from, if you allow for NAT, and that starts to go away some here. It may indeed be an ok idea to limit the lifetime of these QUIC connections, but you'd probably need to start taking the 1-RTT latency hit for each new connection to really reap a privacy gain- pretend you had never talked to the server before. The spec notes this[1] & mentions the speed vs privacy trade off.
> Making every network-element, every hop, have to add something to the routing table is slow
How do you see the QUIC stream layout relating to routing cost? It's been a few years since I've done larger scale networking but I wouldn't say IP routing changes much between protocols. Router see's destination IP bytes, matches destination IP to network route in table, forwards packet. 10 UDP, TCP or QUIC UDP packets in any stream arrangement are unlikely to route differently or to add/remove cost (in a contrived example ignoring QUIC or TCP protocol overhead). Most "middle" hops are just pushing the packet, at least until you are hitting an AS that controls the endpoint of a connection.
Are you referring to hops where application level decisions are being made? Towards each end of a packets route there may be hops to NAT, QoS, L4 routers or firewalls that will try to reconstruct packets into logical sessions where there's a memory/lookup overhead and usually rules applied to the packet. This is likely to decide where the packet ends up but that's not slow and I don't believe QUIC connections are a fundamental leap in this type of tracking over TCP src/dst 4 tuples, apart from the observability improvements the additional quic headers add onto basic src/dst rules.
Uh sorry, what? You say ""your OS"" so I'm guessing you mean an eyeball device. Routing tables (well, it's just knowing which pid bound which socket really) on eyeball devices is pretty much free at the order of magnitude of a standard website where 99.99% of the CPU and RAM is spent in the browser. I don't even understand what kind of resource we would be talking about here?
I'm guessing I'm missing something, though I can't see what, could you help me?
I deployed DNS-over-TLS on Cambridge University’s resolvers in late 2018, and at that time Android already had a superb implementation, that respected the DNS server’s advertised connection idle times, and used TLS session caching to make reconnection faster.
IIRC an idle time of about 10 seconds seemed reasonable: long enough to be used for all the DNS requests even from a slow web page, but not so long that the server spends ages keeping state that will never be reused.
In general the Privacy Considerations section (7, slightly below what I cited, 5) is quite impressive & well considered. There are pretty strong & conservative recommendations: only use session resumption once, for one example.
I have a lot of faith a) these specs have identified the potential issues fairly well, b) they have adequate & good recommendations, c) most implementations will follw these recommendations, and d) the alarm/alert will go up if implemenatations start undercutting significantly on privacy measures.
Generally I think there's no present due cause for alarm, at all. Privacy is a real concern & risking it is an acknowledged existential risk that no standards bodies would pave over in todays or tomorrows world.
>"There's other abstract concerns though- having multiple short-lived connections in your OS and routing tables consumes resources- minimizing resource consumption is a decent goal."
I'm not understanding this. Your OS's network stack would just see these destinations as not being part of the local network and send these UDP packets to the configured default route. Why would there be a need to create a route?
1. don't put devices with untrusted operating systems on your home network in the first place
2. if you must, put them in a quarantine vlan
a better question is why you have things in your home network that might be sending encrypted dns queries outside of your control, what software or OS is doing that?
I’m a naive person and believe any form of advertisement is intrusive. So by definition anything that wants to show me and my kids ads will eventually try to circumvent any filters in place.
In this case blocking outgoing traffic to port 853 would be enough, but it won't stop DNS over HTTP. I've not found a good way to deal with that one if you want to control things, other than requiring all devices support your CA and you inspect for it.
Things that do DNS over HTTP are asked to respect the use-application-dns.net canary. If use-application-dns.net queries are blocked by the local resolver, the thing should use the local resolver, unless there is a manual override by the human user.
This is a bad idea. ISPs will use this to force users to send queries in plain text. There is no need for this feature.
One might say that a corporation might need this. But why should we care about corporations? Let them use Internet Explorer that sends everything in plain text. Or they could configure using unencrypted DNS in group policy.
Encrypted DNS should be indistinguishable from any other HTTPS traffic.
Let's suppose that I have a home network, from which I make certain things available to the Internet. Those have public DNS records and appropriate ports are passed through the firewall.
I also have a bunch of machines that I like to have names for, but I don't want the Internet as a whole to enumerate them. Why? Because I like my privacy.
So I run my DNS in a split-horizon mode: everyone sees www and mail and blog, but only IPs inside my house get to see the A, AAAA and CNAME records for spike and splorch and sporty, den-tv and lr-tv, music and video.
But then Firefox and Chrome enable DoH. I can provide DoH, no problem, though I prefer DoTLS. The problem is that they don't ask my local DNS servers via DoH, they ask 1.1.1.1 and 8.8.8.8 or such. And those servers, nice as they are, aren't allowed to see the record for den-tv.
So I tell my DNS server to return an error for use-application-dns.net, and everything continues to work.
Meanwhile, my friend comes over and sits in my living room, using my wifi, but my friend is paranoid. They don't trust me at all. So they use a VPN back home. Oh, sorry: they trust me enough to be their next hop, but not enough to use my DNS. So they tell their browser affirmatively that it should use DoH to somebody off in The Cloud That Is Certainly Trustworthy, and that works too.
I couldn't disagree more. I'm far more concerned about device vendors leveraging encrypted DNS in order to remove my ability to intercept and filter DNS resolution on my own network.
For example, I'm sure Google and pretty much every Smart TV vendor would love it if we could no longer easily block traffic for streaming ads, sending telemetry, etc.
So enterprise-class firewalls can presently identify and block the QUIC protocol entirely. (If you have such a firewall, I recommend this! Nothing supporting QUIC has no fallback.) Hopefully that level of intelligence will eventually make it down to at least prosumer-grade firewalls, but the folks who buy D-Link and Linksys stuff are probably out of luck.
For the love of all that is holy... DNS should be UDP (or eqiv), as most building block protocols of the internet. _that doesn't mean it needs to be unencrypted_. Wasn't there DNSCurve a thing at one point that was the best of all worlds?
DNS has always supported UDP and TCP. Traditionally queries used UDP and transfers TCP but this wasn't a requirement of the protocol. With the advent of EDNS and large responses such as those when DNSSEC is involved TCP was increasing being used for queries even before DoT or DoH.
QUIC is UDP based so by being able to handle large responses DoQ reduces the need to use TCP and brings your vision of a UDP only DNS closer to fruition.
DNS has always supported TCP. RFC 1034, published in 1987, made it a requirement. DNS uses TCP when replies exceed 512 bytes(barring EDNS0.) DNS also uses TCP for zone transfers. There's even a bit called the TC(truncate) bit which when set in a response informs the client to use TCP.
CurveDNS, an implementation of a dnscruve forwarder, works great. I use it on the home network. To see an example on the internet, try
x=$(dq -a a ianix.com 192.5.6.30 |sed -n '/authority/{s/.* NS //;s/\..*//p;q;}')
dq -a -k $x a ianix.com 104.207.143.9
dnscurve comes from the same author as the underlying encryption used in dnscurve and QUIC (and countless other solutions), and both NaCl and dnscurve predated QUIC. Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO. The author of NaCl and dnscurve was not interested in personal data mining and selling advertising services, unlike the corporations behind QUIC. Oh well.
See Section 7 of RFC 9250 that is the subject of this submission.
QUIC is designed by a company that prioritises personal data collection and advertising over user privacy with respect to the company. If compromises have to be made in order to satisfy the company's interests in collecting user data and administering programmatic advertising services that include subjugating user privacy from the company, then what happens. CurveCP and dnscurve do not suffer from such commercial pressures. CurveCP and dnscurve were not designed by an online advertising services provider.
Arguments that doubts the origins and not the technical merits are very poor arguments. That’s a slippery slope that can go to any absurd extreme such as asking what’s the proof that CurveCP is free from nation-state pressure because of author’s citizenship?
QUIC, despite its warts, is an open spec that anyone can review. The cryptography is based off TLS 1.3 and to prevent ossification it is fully encrypted (sans two sequence numbers). It’s really easy to read spec - really, try reading it.
Thanks, this was the first I had heard this mentioned and agree the passage doesn't seems grounded in opinion more than technical merit. I was curious about your comment that:
>"The cryptography is based off TLS 1.3 and to prevent ossification ..."
I thought that the protocol choosing the be encapsulated in UDP was the thing that was addressing protocol ossification since UDP will always be supported by OS's network stacks. Or are you referring to something else?
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.
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."
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."
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."
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.
"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.]
I keep seeing this wonderful flexible multicast new protocol (QUIC), but see these really big ways it limits what it wants to take on in really harmful ways. The unreliable datagrams spec, for example, punted entirely on multiplexing[1]. Every unreliable protocol that needs different "streams"/channels then has to go invent streams all over again, but there's no guarantee the different implementations will be compatible & able to share the one and only unreliable data-channel datagrams affords. This is easily witnessable in MASQUE[2].
Ideally I'd like to see some kind of standard for declaring protocol, so different streams of different protocols can "just work" over a shared QUIC connection. And I'd like to see streams brought to datagrams, with perhaps one shared/default "global" (per-connection) stream alike what we have now. There's so much good protocol work here, but we keep being just short of making it easy to layer things in; so close, but falling in critical areas for lack of ambition.
[1] https://quicwg.org/datagram/draft-ietf-quic-datagram.html#na...
[2] https://blog.cloudflare.com/unlocking-quic-proxying-potentia... https://news.ycombinator.com/item?id=30744739 (4 points, 57d ago, 2 comments)