This is a great summary and I agree with the findings mostly. I think we should separate the "DoH the protocol" from the "DoH decision of using a public resolver". For "DoH the protocol", widespread adoption by most users' default resolvers is about as likely as widespread adoption of DNSSEC and DoT. For "DoH decision of using a public resolver", that decision can be done today with resolvers that support DNSSEC/DoT.
So if we want users to use a hardcoded default resolver different than their ISP's, come out and say that and stop conflating it w/ the protocol. If we want users to use the DoH protocol, we're in the same boat as asking them to use DNSSEC/DoT. Therefore, for the idea of a hardcoded default resolver in one browser, if it's really something a browser wants to do, why are they waiting on a protocol? And for the idea in another browser of checking known protocol support of the existing resolver, do/can they do that with DoT too? And can they do something besides a hardcoded list to check resolver capabilities (i.e. can I return an additional record/bit from my DNS servers that is essentially DNS equivalent of HTTP Alt-Svc to say I support DoH)?
The entire premise of DoH and DoT are that you don't want to use your ISP's DNS. Nobody needs to "come out and say that"; it's whole point. They're both mechanisms to tunnel DNS out of your network to somewhere safer. The difference between the two is that DoT has a network-operator kill switch, and DoH doesn't.
> The entire premise of DoH and DoT are that you don't want to use your ISP's DNS
This is the discussion separation I am requesting. There is benefit of in-transit encryption regardless of who the endpoint is. There may also be benefits to defaulting to non-system DNS, but those discussions should be separate IMO.
What's the benefit of encrypting your DNS traffic to the ISP? There isn't anyone between otherwise they'd be your ISP. The point of DoH is to provide a way to configure DNS to something that isn't the ISP without the ISP being able to block it, snoop it, or intercept it. There is no separating the concept because if you're doing it to the ISP then the reasons for doing it are now invalid.
Also "not the ISP" != "non-system dns". Don't conflate that just because browsers were first/most famous to implement.
I specifically said endpoints and not ISP because the proliferation of encrypted DNS traffic is a good thing regardless. Also, there is still MITM potential between you and your ISP's DNS server as many ISPs share pipes that have been known to be tapped at different PoPs. The value of encryption to DNS servers is obvious, even if we pretended that user-to-ISP traffic was all we were talking about.
I liken these arguments to the same ones made in the past by our more-naive selves concerning encryption of corporate intranet traffic. We should be smarter now.
Replace ISP with endpoint, the conversation is the same. Simply encrypting to whatever the other end of the cable tells you to is false security. If the other end of the cable is malicious it will just lie about what your DoH server is. You can establish identity with a CA infrastructure and a precoded default destination, this is what DoH is about
Encrypting traffic, internal or external, only makes sense if you don't trust whatever you happen to plug in to tell you what to trust. OWE in Wi-Fi has similar faults.
Using someone's resolver other than your own is sensible: it serves to hide from authoritative servers the IP addresses of each query's requestor, both because the resolver aggregates many clients' lookups, and because of caching.
But whoever runs the resolver you use gets to see what domainnames you're resolving. Your resolver's operator will be sorely tempted to monetize that metadata.
Your only choice is which resolver operator you'll allow to monetize your metadata.
So you lose no matter what, unless you have a contract with the operator, and then you'd better be giving them something of value if you want to be able to enforce the contract's confidentiality requirements.
ISPs mostly don't even support DoH/DoT, which is a reason to not want to use their resolvers. But using public resolvers helps centralize the DNS, which is not good.
Yes. If you're concerned that your third-party resolver is monetizing or otherwise monitoring your DNS, you can run your own DoH recursor, semi-anonymously, from a public cloud account. In the long run, presumably trustworthy organizations will stand up DoH resolvers that people can trust.
I preemptively agree that Cloud Flare is not one of those organizations.
It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.
> It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.
Perhaps a parent wants something that's easier to filter.
Yes; Paul Vixie is to DoH what I am to DNSSEC, and his consistent case is "DoH is bad because it's hard for network operators to turn it off for users". To me, that's a ringing endorsement.
And to me, who works in IT, it's a bloody annoying.
We've already implemented the use-application-dns.net NXDOMAIN canary at work because after some testing Firefox breaks a bunch of apps because of split-horizon DNS.
There's already (at least) two malware that's using DoH to get around network monitoring:
I absolutely understand why it's bloody annoying for network operators. What I don't understand is why any home user should trade even the tiniest iota of their privacy to make your life any easier. You get paid to deal with these problems.
In certain situations, even home users are in the same position as network operators. The processes running on their machines will use exactly these same mechanisms to escape the user control. The last few years have shown, that big brand names are not to be trusted, and their interests, as implemented in their software, are not aligned with user interests. In a way, we are getting back full-circle to Stallman.
I don't understand whether you're saying that DoH+ESNI will make it harder for malicious network operators to compromise user privacy (clearly true) or whether DoH+ESNI will make it harder for home users to run their networks as if they were enterprise networks.
It would be a genuinely weird new take to argue that encrypted SNI was somehow harmful to privacy.
> It would be a genuinely weird new take to argue that encrypted SNI was somehow harmful to privacy.
As a 'network operator' at work and home, it is my responsibility to keep my network clean. Both for my own sake and for the sake of the greater Internet (is malware being spread from my network?).
End-host security is used to make sure that connected systems are clean. But if the end-host is compromised, then that may now become useless. So a second level of security is network monitoring.
However, how can I be responsible network operator if I have no visibility into my own infrastructure? DoH by-passing local DNS, and ESNI cloaking the destinations, make it impossible to see who is doing what. At least with Do53 (and DoT) I can control lookups (possibly to C&C servers).
What is privacy? The same way the home user can get privacy from the network operator, can malware get its privacy from the home user.
This is amplified by moving DNS resolution into applications, Mozilla style. Now even the operating system or local firewall applications (Little Snitch, etc) can't know, where the processes are connecting.
Again, the application vendors can have objectives that are not aligned with the users. It is a mistake to conflate the home users with random applications running on their computers.
The argument is, that a random process should not be a world into itself; there should be a way to check on what it is doing. It does not have to be network based, it can be done by another process on the local machine. Things like DNS should be done by the OS, with hooks for the monitoring. It should be not be done by the application, with zero transparency to the owner. The system resolver, on the other hand, can use DoH/DoT/ESNI/whatever.
Giving random processes unlimited, uncontrolled and uncontrollable access to Internet is disaster waiting to happen. Quite similar to what happened to applications on Android.
I don't know, whether I'm expressing badly due to English not being my native language, or where is the problem in understanding. I hope that you are not just misunderstanding intentionally.
So once again: The combination of ESNI and DNS resolving inside applications (and not OS, not checked by some user agent) provides privacy to application, not users. That application might or might not have its objectives aligned with the users; more often than not, it will focus on interests of its vendor instead. So conflating privacy for application with privacy for user is mistake.
By applications using custom DNS+ESNI, the user loses control over who the application communicates with, he just sees that it can send and receive blobs. What it is sending out, to whom, is and will be unknown. That is the negative wrt user's privacy, compared to which the current Android ecosystem is squeaky clean.
If you were counting on DNS and SNI monitoring to detect compromised endpoints, you’ve lost anyways, because malware can chose its own dns resolution method and avoid SNI regardless of what the OS or Firefox are set up to do.
Even better, Malware can (popular malware doesn't so far as I can see today, but could if other methods stopped working) straight up lie in SNI and in the old TLS 1.2 plaintext Certificate message, and produce plausible yet entirely misleading results in your inspection apparatus.
A real client expects the encrypted parts that follow Certificate to match up and should abort if they don't, but malware is under no obligation to do that, and a 3rd party which can't decrypt the rest of the handshake won't know e.g.
Malware client: SNI for bigbank.example (knowing bigbank will have been excluded from snooping rules at the target)
Malware C&C server: 100% Legitimate Certificate copied from bigbank.example
Malware client: Cool, let's continue with encrypted setup (ignores the pretence that this is bigbank.example and now communicates with the C&C server undetected and encrypted knowing the logs will just show "bigbank.example")
"Security" products can't protect against this without snooping each and every single transaction, but many will be deployed by ignorant/ well-meaning people who don't understand how this works and thus that the products can't actually do what they appear to offer to do.
Yes, but the malware isn't required to use port 53 or "plain DNS" at all...
Regardless of what the OS or Firefox or whatever existing app uses, a malicious binary could just use DoH, or just make an HTTP request directly to an IP, or skip HTTP/DNS entirely and fling data out over UDP to an external IP.
Put another way: if your issue is that DoH removes your ability to catch DNS requests from malware, your issue isn't with users enabling DoH, or with app devs defaulting their apps to DoH, your issue is with the concept of non-DNS network protocols. Even if DoH was never standardized, an attacker isn't required to make lookups on port 53 as you desire.
> I preemptively agree that Cloud Flare is not one of those organizations.
Would you please elaborate on your distrust of Cloudflare? I’m not looking to call you out. Quite the opposite, I appreciate your candor. I just feel like I’m missing some context.
I'm not comfortable getting into it here. Just suffice it to say that my support for DoH has absolutely nothing to do with Cloud Flare's support for it.
We all should be worried about loss of privacy, but we can't all run our own resolvers on the cloud.
The choice of DoT vs DoH will mostly be about what is supported by one's choice of resolver. Of course, choosing DoH first will narrow the choice of resolvers.
This is a false controversy. The people that "can't" run their own resolvers are, overwhelmingly, using their ISP's resolvers. At least in the US, all of those ISPs are actively attacking their users. Users are better off using practically any other mainstream centralized DNS provider than their ISP default.
But this isn't a stable equilibrium; as I said, it seems clear that privacy-minded organizations will eventually stand up their own trustworthy DoH resolvers.
DoH makes things somewhat better today for all users, and much better for power users. In the long term, it's easy to see how DoH makes things much better for everybody.
Running one's own recursor using DNSSEC via an ISP's resolver (for the privacy benefit relative to authoritatives) would take care of active attacks by ISPs on their users. Windows and Linux could do this you know, but security would be enhanced only relative to sites that use DNSSEC.
But I don't disagree that DoH is better.
I do hope that in the long run ISPs become less toxic.
Running one's own resolver with DNSSEC would do absolutely nothing about the ISP threat, since DNSSEC is a cleartext signing-only protocol. Since the overwhelming majority of zones aren't signed, it won't even protect you from the garish NXDOMAIN landing page attack.
I was referring to active attacks. I don't consider an ISP or a public resolver operator to be particularly different w.r.t. passive attacks: both get to do it, and both do do it.
Tricky question. I'm the chairman of Quad9's board of directors. So _I_ trust the organization. But I'd urge everyone else not to trust _any_ organization, but instead to do as much to protect yourself as possible, using an external recursive resolver only when you need to.
That means running your own caching resolver, with a local copy of the root zone and QNAME minimization enabled, and then using DNS-over-TLS to forward the minimum necessary query onward.
The next question then becomes whether to perform recursion yourself (by talking directly with authoritative nameservers) or to have Quad9 or another recursive server perform the recursion for you. Authoritative nameservers don't yet support transport encryption, though we're working very hard to support it on the 500 TLDs PCH is authoritative for, and Verisign is working very hard to support it on .COM and .NET. So that means that your traffic is subject to interception, and essentially all authoritative servers either log queries or have people logging queries off the wire in front of them. And if you're handling your own recursion, everything you don't have cached crosses the wire, and none of it is blended together with anyone else's traffic.
To make the decision as to whether it's better to trust a recursive or send queries directly, knowing something about the practices and purpose of the recursive is necessary. Quad9 is the only major recursive that's a public-benefit not-for-profit. There are other small ones which are not-for-profits (like the Taiwanese 101.101.101.101, operated by TWNIC), but all of the others that come near Quad9's scale or traffic are for-profit, operated by companies that monetize data. Quad9 and Cisco's commercial Umbrella service are the only two which are GDPR-compliant and thus legal to provide to European citizens.
Quad9 exists solely so that bad choices won't be the only choices.
-Bill Woodcock
Chairman of the Board of Directors
Quad9
The major difference between DoH and DoT is that DoH is a proxy while DoT is end-to-end. With DoH we assume that the client connects to the central DoH server and beyond that there is dragon. There is no such design in DoT and the resolver is set to independent create DoT connection to all other resolvers in the chain.
If we are concerned with kill switches, the end-to-end design is less fragile to malicious and legal attacks than a proxy scheme with a handful of operators.
That is entirely wrong. My implementation of DoH and DoT (running in production at the University of Cambridge) uses nginx as a proxy for both protocols in front of our normal recursive DNS servers. DoT is widely used by Android devices on our wireless network; DoH is only being used by a small number of lunatics such as me.
I have never heard anyone propose that DoH should be running in front of authoritative resolvers. DoH is strictly a recursive DNS feature where the client contact the recursive resolver and the recursive resolver on the behalf on the client goes and gather the answers to the query. People can disagree on the terminology here but I call that a proxy.
With DoT there is little reasons to not apply the same technology to authoritative resolvers. Conceptually it is almost as simple as supporting both UDP and TCP, and with the low number of root authoritative servers you can even store locally the address and certificates as part of the operating system. Since a lot of TLDs already have signed roots for DNSSEC it is even a pretty simple move forward to imagine a TLS support being enabled by them and the root. I would be amiss to not mention that Bind already store address and root zone keys of root servers as part of the install package.
A bit of a tell is that there is an RFC for authoritative servers running DoT. It is called aDoT. There is no RFC for DoH, and no one is talking about aDoH. Authoritative servers running DoH is not on the map, but aDoT is. Again we can disagree on the terminology but this is the reason why I see DoH as primary a security tool for proxying DNS request while DoT can be used for end-to-end.
None of the authoritative DoT drafts have even been adopted by a working group yet, so based on the usual IETF timescales means they are probably years away from an RFC.
There are still substantial problems to be worked out wrt working out if an auth server supports DoT without slowing things down horribly, and working out how to authenticate a server without getting mired in EPP and the ICANN/registry/registrar policy swamp. The threat model needs to be clarified: do we need to protect against active attacks (much more difficult and stronger authentication required) or just passive snooping (which allows opportunistic upgrade). Does TOFU make sense?
So many questions still to be resolved, as it were
The idea that communication between resolver and authoritative servers should be encrypted is not a new concept. People have been discussing and talking about it for, I would like to say decades. What it does not have is an opportunity for data collection and there is not multiple companies competing to become the central location for dns query data. There is no default setting which a company might pay a significant sum for. Like DNSSEC there is also very little to be gained by authoritative DNS server providers in return for any added complexity. Since I work in this industry I can with fair confidence say that for most registrars the added risk and complexity is the primary reason why security technology in the DNS space is not moving like it does in other areas.
It used to be the same thing for email servers but googles attitude more or less changed that. If you do not support TLS then google is more likely to mark your email as spam. The cost of installing TLS is significant smaller than the cost of users email getting flagged as spam, so within a very short time window most email providers suddenly started to support TLS. Getting people to care about security is often a simple matter between risk and cost, a fact often brought up by Bruce Schneier.
> Does TOFU make sense
There is many potential schemes but one of the more simpler one would be to use DNSSEC and hardcode the certificates of the root servers (Authoritive server programs already hardcode some information about root servers as they rarely change). About 1398 of 1527 TLDs have signed zone in dnssec and it would cover most lookup. In theory there is nothing to prevent the root server from simply publishing TLS keys next to the NS records, with registries doing the same. Looking at how communication between email servers became TLS protected, they did not resolve all those questions and yet we went from all plaintext to almost all encrypted in a few years.
As side note, let me give one example of a business concept. When you buy a domain there is usually a way to get analytics of how the domain get queried. Information like how often and from where which helps the domain owner get a perspective of how their domain get used. Let now say 80% of the traffic get routed through cloudflare. 80% of the logs are now gone. That is sad but you can buy it back If you move your DNS to cloudflare which will happy provide analytic for your domain. All Pro, Business and Enterprise plan customers will even get additional geographical information.
I don’t mean to be hostile, I just want to make it clear that it is wrong to say “DoT is end-to-end” and wrong to say “there is an RFC for authoritative servers running DoT”. It might possibly happen at some point in the future but there is a lot of work still to do before then.
The reason aDoT exist is that DoT was written under a specific charter. To quote the RFC 7858: It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter.
There is nothing inherent of the DoT protocol that forces a model of client->recursive->authoritative. The RFC is pretty light on even mentioning recursive. It mention a technical aspect of recursive client in exactly one place, which is when discussing connection reuse for multiple requests by saying it should (not must) reuse TCP connection if possible. The RFC really just boils down to the concept of applying TLS to a tcp and udp based protocol.
The DoH RFC 8484 is very different and as mentioned above there is no one who is suggesting to apply it in any form beyond as a technology between stub resolver and a recursive server.
The dns-privacy IETF is quite relevant in context. If we want to be technically correct here, there is a draft RFC for authoritative servers running DoT called aDoT, with DANE as authentication.
Lets imagine a DoH protocol for email where Google or Microsoft suggest that email client should ignore smtp setting and send all email to them by default, and compare that to current model that we use today where client talk securely to servers and server talk security between each other. When viewed like that, is it unfair to describe DoH as being a proxy and the model of just adding TLS as being end-to-end?
There's a tension between using private, semi-public (ISP-run), and public resolvers.
The more clients a resolver has, the better the privacy protection it offers vis-a-vis authoritative servers, so there's some reason to want to use one's ISP's resolver, or even a public resolver.
On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data.
Regardless, ISPs need to adopt support for DoT and DoH.
Lastly, it'd be nice if we could get authoritative servers to support DoT/DoH, but that will take a long time.
It'd have been nice to have settled on DNSCurve for confidentiality a decade ago... Even assuming Curve25519's eventual obsolescence, it would have served us well while waiting for a better solution.
> On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data.
To be clear here, your ISP will still know what sites you visit, unless you are using a VPN. There are two vectors for them to gather this information: 1) the IPs are generally pretty stable for most sites (yes that could host many web sites, but still), 2) The SNI is will be sent in the clear for the website to be able to choose the correct certificate for the connection.
That's not to say that there isn't value in DoH/DoT, there still is, but your ISP is still going to be able to follow you around the web pretty easily.
I disagree with the usage of DPI here like it's a significant barrier. Your ISP has access to both the IPs and the SNIs. They can dedicate resources to log them or not to. SNI requires only a little bit more processing power, but otherwise they "know" both.
This work is landing in parallel with development of eSNI, encrypted SNI.
If you have a Firefox with this stuff switched on (so it uses TLS 1.3, eSNI and uses CloudFlare's DoH server), and you go to a site that's proxied by CloudFlare, only CloudFlare [and the site] know which site that was, an ISP sees only that you connected to CloudFlare (duh) and did some HTTPS transactions.
There will be SNI in the ClientHello, but it's generic, it doesn't say which CloudFlare service you wanted so it doesn't help an ISP to log that. The IP belongs to CloudFlare so they learn that, but the rest is a mystery.
All the stuff that makes this go lives in DNS. For privacy you should use DoH to go fetch it. For authenticity you should use DNSSEC to verify it. Proposals are under development for how to land the final DNS changes with HTTP/3 in there as well, so that a single query protected by DoH + DNSSEC can tell a browser "For HTTPS speak QUIC on this IP address and send this fake SNI, then use this eSNI encryption key to hide the real hostname".
But already the prototype with boring TLS 1.3 and HTTP/2 works just fine in Firefox builds with it enabled.
I'm really looking forward to tls1.3, but there's still a bit of time before it gets widely adopted. CloudFlare proxy will help a lot where they handle the connection, but there's lots of services which will take years to upgrade.
It'd be nice if we could settle on DNSCurve for authoritative servers even now. It's significantly simpler and more efficient than DoH and the only real advantage DoH has over it (less interference from quarrelsome middleboxes) isn't nearly the problem between recursive and authoritative resolvers as it is between clients and recursive resolvers, because recursive resolvers are almost always operated from networks that are responsive to their administrators.
It's simple if you pull in a dependency on a library that does it for you, but that's just putting the complexity in the library. HTTP is a complex protocol, TLS is a complex protocol, even just using TCP isn't exactly simple or advantageous to response latency.
Trusted mainstream implementations come from use. You might get the same number of vulnerabilities from a green new DNSCurve library as from old battered OpenSSL because you're trading off the protocol complexity against the years of grinding away at all the bugs, but that only gets you to parity. Which itself only lasts until the DNSCurve library is trusted and mainstream and claims the advantage because the younger code matures but the protocol stays simpler.
In the meantime DoH still has worse latency because of the extra round trips. Especially in the authoritative case where you're typically making few queries each to many authoritative servers instead of making many queries to one recursive resolver and you can't reuse the one handshake for all your queries.
Personally I trust much more the authoritative root servers than public resolver. The root servers economic model is being the backbone of the Internet, they are not advertisement companies, they have a long history of working as an infrastructure, and there is very little incentive to monetize that data. The risk of a fork in the DNS system has always been the sword that kept the authoritative root servers honest.
If authoritative root servers started to support DoT/DoH/DNSCurve then clients could do secure end-to-end communication with simple two hops in the vast majority of cases. In the case of news.ycombinator.com it would ask .com for ycombinator without informing the TLD server of the remaining parts of the domain, and then ask ycombinator.com for news. Simple end-to-end communication without giving out unnecessary information to any party.
I have asked that question a few times in conferences. Capacity wise they can handle it as they already need it to defend against the massive DDoS threat that they face. Relative recently they also added anycast, which further increases the capacity.
DNS queries is also generally quite small and has not significant changed, and the modern resolver software is pretty efficient. DNS is also designed for redundancy so in combination with anycast is quite simply to scale up.
Because of the persistent DDoS threat the question of capacity is constantly discussed. I don't remember the exact numbers but the current overhead is quite large compared to actual usage. It is also constantly being increased based on the threat rather than usage.
I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser.
Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites?
> I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser.
That's not a reasonable position. Never before in the history of computing has a regular end-user application actively tried to subvert the operating-system's network defaults.
Why should anyone expect that to be the position now? Should I expect Thunderbird too to bypass my DNS-settings? What about Rust's cargo? It's from Mozilla too.
Will I need to manually go configure all those tools to do what is the reasonable default, namely following what the OS tells it to do?
When Firefox fails to resolve a domain, but nslookup resolves it just fine... What should I as an end-user believe? (Besides that we have an orderly world turning into chaos)
Do you really think every application choosing, managing and implementing its own resolver is a scalable way of managing applications and networking? Really? Yeah no. So why should browsers get a free pass do things differently?
> Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites?
No. But that's not what we're talking about here.
What has always been a clear expectation is that if I sign up for an ISP and I use that ISP's default network setup, that I will be using that ISP's DNS. Never in the history of ISPs has there been any other default.
So if I may rephrase your question:
> Was it explicitly clear to you that by using an ISP as an ISP, you will also by default use their DNS services?
Obviously. That's how the internet works and has always worked. In fact, anything else would be strange.
Unless I explicitly implement something differently, I have no reason to expect anyone besides my ISP (which I do trust, I'm not from the US) is handling my DNS.
Unlike my ISP (which I trust), anyone who deviates from this contract will be someone I actively distrust. I'm looking at you, Mozilla.
Mozilla does not have this kind of influence over Rust. They've never indicated that they'd want us to do this, we've never thought that doing this is something we'd want to do, but if they told us they wanted it, and we didn't want it, it wouldn't happen.
> That's not a reasonable position. Never before in the history of computing has a regular end-user application actively tried to subvert the operating-system's network defaults. ... Will I need to manually go configure all those tools to do what is the reasonable default, namely following what the OS tells it to do?
For starters, just because the OS provides its own name resolving facilities doesn't mean it's telling applications to use it. It's there to make application development easier, not as a security feature.
> When Firefox fails to resolve a domain, but nslookup resolves it just fine... What should I as an end-user believe?
The end user should believe what the error message says, because we don't design web browsers with the expectation that the user understands how DNS works. And if they do, then I don't see why it's so onerous to ask that they also learn how DoH works, given that having that default is in the best interest of the majority of the product's users.
> Do you really think every application choosing, managing and implementing its own resolver is a scalable way of managing applications and networking? ... So why should browsers get a free pass do things differently?
Yes, I don't really see how that's such a big scalability problem like you're making it out to be. It is obviously necessary that any networked application will manage and implement its own purpose-built network protocol already. That is a significant amount of complexity necessary to any networked application, and name resolution is just a small function in comparison.
Furthermore it actually does make sense for web browsers to have special behaviour here since they are almost never used to connect to LAN resources, just internet resources, which is unlike many other networked applications. They also make up a widely used application platform which has specific security and privacy needs that other networked applications don't have.
> No. But that's not what we're talking about here.
It's what I'm talking about, because I don't see how to make sense of your "Firefox is malware" analogy otherwise. Your ISP picked a default, Mozilla picked a different default.
> What has always been a clear expectation is that if I sign up for an ISP and I use that ISP's default network setup, that I will be using that ISP's DNS. Never in the history of ISPs has there been any other default. ... Unless I explicitly implement something differently, I have no reason to expect anyone besides my ISP (which I do trust, I'm not from the US) is handling my DNS.
I don't think that's a clear expectation to most of the people who are in fact sold internet access without being trained on how DNS works. I also believe that Mozilla very clearly communicated that they were changing this default, through many channels, to Firefox users. So your implication that Mozilla is doing something sneaky here is ridiculous.
I'm sorry that this change broke your PiHole config but you can fix it easily. New software sometimes breaks your old configs. That's life. If you want an ad-blocking solution that isn't so brittle, then try installing uBO on the client rather than abusing DNS for that purpose.
Great summary. The user's threat model could be more succinct and address the question of what the end user is really protecting, and from whom. Then the features of the different protocols would be mitigations to that risk.
I've got a horse in the race, but I might use it as an example input for the method in this post: https://www.qtra.io/simpletm
Short version would be, <end user> wants to protect the <confidentiality and integrity> of the <contents of their browsing history> from:
<isps> who <using it to target ads and sell to 3rd parties>
<intelligence agencies> who <are engaged in bulk collection>
<employers> who <use browsing history as leverage to manage out staff.>
etc.
We need the who, why, and what, before the how. Excellent summary all around though.
Great discussion. I also think that the more we talk about it, the more and better solutions will start appearing to solve all the problems that come with choosing DNS providers. There is also one issue that we don't discuss too much. I understand that by selecting a private DNS resolver over the ISPs DNS, you still provide your info to that resolver's operator, and they can monetize it. And here I see one crucial thing - choosing the provider that HAS to collect your data over choosing the provider that doesn't do it. Correct me if I'm wrong, but basically, any DNS provider located in the USA is required to collect and store your data by law. So it's not only easy to use that data for monetization, but also they would be required to give all that info to the gov if needed. I was going through a list of most popular DNS providers, and I didn't quite like what I saw. But I found this Trust DNS app (https://surfshark.com/trust-dns) that as a product from Surfshark is also located in the British Virgin Islands. So technically, they are not required to collect any users' data, and they state that they don't. There is also an option to switch between DoH and DoT. The only downside is that it's only for Android right now. Any thoughts about it? Are there more options that are not based in the USA or other 14 eyes countries (or well, China)?
More attention needs to be paid to QName minimization, IMO.
DNSSEC is the only truly hierarchical PKI with pervasive name constraints that we have. That makes it very valuable, even if it is difficult to leverage to solve other problems.
Like all PKIs, DNSSEC is vulnerable to authorities (that is, authoritative servers) acting as MITMs. WebPKI makes it very easy for nation states to acquire MITM credentials: just subvert a national CA and you're done because the WebPKI lacks name constraints. A real PKI makes this harder, because a nation state can only legally subvert authorities within its jurisdiction.
The root zone is special though, as long as there is only one, and that's why the root zone operators make such a special show of key signing events: to increase confidence that it has not been subverted. But the root zone is still a concern -- if not today, then tomorrow.
Enter QName minimization. By sending minimized queries -at the cost of having to do more queries, thus having higher latency- one can keep intermediate authorities from observing the full domainname that one is attempting to resolve. That makes is more difficult for authorities to MITM specific targets.
The opposite claim is closer to the truth regarding "true hierarchical PKIs" versus the WebPKI. In reality, if a state suborns a CA to misissue certificates, Mozilla and Chromium will nuke that CA from orbit. You don't have to wonder about this; Mozilla and Chromium casually destroyed some of the largest commercial CAs. Moreover, misissuance is very likely to be detected, because Chromium and Mozilla have moved towards requiring Certificate Transparency participation.
On the other hand, if a state suborns its DNS providers to inject bogus keys, there is no recourse. You can't revoke .COM. Is Google going to become Google.IO? Wait, no, .IO is controlled by Five Eyes as well.
> Mozilla and Chromium casually destroyed some of the largest commercial CAs
While I agree with much of your comment, I think you are doing both Google and Mozilla a disservice to say they did this "casually". The decisions to distrust the CAs in question were not taken lightly; they came after repeat offences, and the grounds for doing so were abundantly clear.
It's also possible for a state to suborn a registrar to publish a fraudulent record so that the state can get a DV cert issued by the CA of its choosing. This leaves the WebPKI in no better shape than DNSSEC + CT when it comes to state level attackers obtaining fraudulent certifications.
This is of course why DNSSEC is crucial anyway. DNS is the foundation under the Web PKI, a secure Web PKI on top of insecure DNS doesn't buy you very much. It's impressive we've got this far in fact.
It was most fun in the old days, before the Ten Blessed Methods. You'd get this contrast between the wild imaginations of anti-DNSSEC people who imagined every certificate application is investigated by some combination of Jason Bourne and Sherlock Holmes - and a reality where it's just somebody got a blurry fax from a law firm in another country and so they pressed OK because everybody knows lawyers are honest.
I don't know what you're on about with this "Sherlock Holmes" stuff, but the last several CA kill-shots occurred after Google and Mozilla detected misissuances. And Google and Mozilla didn't just revoke the certificates: they killed the CAs themselves.
Are you not watching CT logs for domains you work on?
As you definitely ought to know if you had any idea about this topic I run a complete Log Monitor for my employer these days and so in that sense I am watching all of the public logs.
I also run smaller monitors and auditors for my own interest as an active participant in m.d.s.policy. Which is why it's always weird to hear your version of what goes on there, since you don't participate and seem to base your understanding on something like a tabloid newspaper report or a Hollywood script rather than the reality.
I don't post on m.d.s.policy or any other standards or community organizations, both because I think all of these sewing-circle groups are a net-negative for security (we'd be better off just letting Ryan Sleevi call the shots), and because not a single one of them them would be better off if I was there mouthing off. I feel like more people --- I can name specific people --- should consider following my lead on this and getting the fuck out of the way on task-oriented forums. There's plenty of other places --- like HN --- to say what I think, and synthesize what I've learned from other people.
Don't mistake any of that for me not keeping up with these groups. Your arguments still have to make sense to succeed; you do not in fact have an "I post on m.d.s.policy" card to play here.
> From my perspective, I believe that we should work on pushing for wider adoption of DNSSEC, because I continue to come back to the core problem of DNS results not being authenticated or verified.
Can we replace DNSSEC with something that doesn't give government control over root zones?
I suppose you could have blockchain DNSes. Indeed, attempts have been made. Of course, then you get the same problems as with cryptographic coins, where getting 51% of mining resources lets you double-spend, which for DNS would mean letting you MITM specific targets. And guess what governments would do about that?
Repeat after me: rubber hose cryptanalysis is unbeatable / cryptography cannot solve political problems.
tptacek has a tendency to deny the existence of problems that he doesn't consider to be important, and thus his criticism of DNSSEC tends to go a little bit too far. He does a great job of explaining what's wrong with DNSSEC and I agree with the general conclusion that it's not worth the trouble, but his blindspots are a bit annoying.
Not OP, but in particular one of the major points of your post about the issues surrounding DNSSEC is that TLDs are controlled ultimately by the government with jurisdiction over them. Specifically I'm talking about the section titled "DNSSEC is a Government-Controlled PKI". You present the argument that the existing CA system is more protected from government interference than registrars. I think that argument is pretty weak considering that for the most part we're just talking about DV certificates and all a DV certificate from a CA signifies is that that particular CA verified that the entity they issued the certificate to controlled that domain. When ICE seizes a domain name, they can get a DV certificate no problem, they own the domain at that point. If Muammar Gaddafi ordered bit.ly to be seized for some hypothetical "Bureau of Information Technology", he could have absolutely gone to any CA afterwards and gotten a DV certificate.
Why should a litany of CAs with authority to sign certificates for largely any TLD be preferable to only allow the entity that's authoritative on domain ownership being able to sign valid certificates? DV certs are just indirectly checking with DNS anyways and there are pitfalls in that process and no real benefits in the end.
Google and Mozilla can (and likely would) destroy the CA that allowed an unauthorized Gmail.com (not DNSSEC-signed, by the way) certificate to be issued. They have destroyed some of the largest commercial CAs in the industry for less.
Neither Google nor Mozilla can revoke .COM, and the USG has repeatedly used its authority over .COM for public policy ends.
Yet they haven't, and never will remove CAs that sign certificates for domains that ICE has seized. If the US government actually took the extraordinary step of just flat out taking ownership of gmail.com under the guise of some anti-trust action then they would meet the requirements to be issued a DV cert anyways.
If the USG actually did seize control over gmail.com, and they had some CA sign a DV cert for them, how would that constitute a misissuance? The whole point of a DV certificate is that it only attests that the owner of the cert is the owner of the domain. The scenario we're talking about is a government becoming the new owners of a domain name.
But regardless of that, mitigating government overreach by means of having hundreds of sacrificial CAs is a pretty poor solution. What happens if Let's Encrypt gets blacklisted? That's a huge chunk of the internet gone right there until everyone gets around to replacing them. IANA doesn't have to have the root and TLDs delegated to a single entity. DNSSEC could be replaced by something requiring signatures from multiple different entities in multiple different jurisdictions to actually solve this problem. Have the root and global TLDs signed by at least 3 out of 5 entities with no more than 2 of those being from a Five Eyes nation. IANA already has a mediation process to resolve disputes with domain names, there's no reason why legitimate domain seizures couldn't be subjected to that process rather than just a unilateral court order to the registrar.
As for killing large existing CAs though, just look at how egregious Symantec was before Mozilla and Google ultimately decided to pull the plug. For years there'd be new ever more creative ways in which Symantec misissued certificates and their responses always seemed to be some variant of "Sorry, we didn't know we weren't supposed to issue certificates to entities other than the owner". There is still considerable friction to removing misbehaving CAs. As a matter of fact, Symantec in particular did misissue certificates for google.com back in 2015 during that whole test certificate debacle.
This is the kind of analysis that makes sense if you read RFCs at face value, or columns from network engineers at CircleID. It does not reflect the real world.
Here's a breakdown of the real world implications of these three protocols. They are in fact simpler than this analysis suggests.
DoT and DoH are related efforts. DNSSEC is unrelated to DoT or DOH.
DNSSEC is a ~25-year-old effort to sign DNS records, so that attackers who control caches can't spoof records. In 25 years, through 3 revisions of the protocol, 2 of them major, DNSSEC has seen practically no deployment outside of Europe, where registrars enable it automatically (and thus control the associated keys). In particular: with the exception of Cloud Flare, which provides DNSSEC services, and some Paypal domains, no major tech companies sign their zones with DNSSEC.
For a bunch of reasons, DNSSEC is probably a dead letter (I'm not calling time of death yet, but I expect to within in the next 6 months). In particular: protocol-level defenses against record spoofing just aren't very relevant. Much of the Internet runs on TLS (if you don't, DNSSEC is the least of your problems). The WebPKI (TLS CA system) has in-progress mitigations against spoofing, and more in the pipeline, and all of them put together will cost a tiny fraction of what DNSSEC will cost. For a year or two, SMTP TLS was the great hope of DNSSEC deployment, the last major mainstream application that had a security gap addressable directly with DNSSEC. But then the major mail providers all (all) got together and came up with SMTP-STS to address that gap directly.
It is hard to think of a real threat that end-user adoption of DNSSEC would address. I like to joke that the DNSSEC root keys could end up on Pastebin today and network engineers around the world could sleep the resulting Jira tickets for a week or two before deciding whether to just backlog them. Except I'm not really joking about that at all.
Which brings us to DoT and DoH.
The problem you do actually have with DNS today, especially if you're in the US, is that your large ISP is abusing DNS to monetize your traffic. I'm on AT&T, and, with their standard DNS, if I type a nonexistent domain into my browser, I'm on an AT&T landing page. ISPs are actively attacking DNS today for all their customers.
DoT and DoH tunnel DNS out of untrusted networks to a resolver on a hopefully more-trusted network (that is: there isn't that much point to DoT'ing or DoH'ing to your ISP's nameservers; you care about DoH/DoT if you want to use a third-party resolver, which you should).
Both DoT and DoH use TLS to secure DNS lookups. Protocol nerds will have fascinating discussions about the tradeoffs between the two approaches, but from a practical perspective, for home users, here's the real difference: DoT has a kill-switch for network operators, and DoH doesn't. A network operator that doesn't want you DoT'ing can stop you, because DoT deliberately runs on an oddball port. DoH, on the other hand, very deliberately runs on 443/tcp, so that it costs more to filter.
Do you want a kill switch in your DNS privacy tunnel? That depends on who you are. If you're an enterprise network operator, you want the kill switch, so you can (reasonably!) force your endpoints to funnel their DNS lookups through recursors you control and monitor. If you're a home user, you very much do not want the kill switch; if you decide you want to use Google DNS rather than your In-Flight Wi-Fi provider's DNS, it should not be up to your airline or their wifi provider whether you do that.
Booz Allen, United Technologies, and Raytheon are government contractors. For several years, the USG had a policy of requiring DNSSEC for its own internal zones and had sent signals that its partners would require DNSSEC as well. But a year and a half ago, the USG rescinded the requirement, and no longer recommends DNSSEC even for internal .gov zones.
Comcast is an interesting example because their adoption of DNSSEC broke a major project rollout: the week HBO NOW became available, it was unreachable from their networks due to a DNSSEC misconfiguration.
Another data point: of the Alexa Top 50 in the US, only FORCE.COM is DNSSEC-signed. But SALESFORCE.COM isn't; similarly, Paypal is signed, but its popular subsidiaries like Braintree and Venmo aren't. Or take the Moz 500; you'll find Mozilla is signed, as are a bunch of .GOV sites (see above), some European sites, and, if we're keeping score in the US, also Fox News, Time, Mediafire, and, weirdly, Themeforest. For reasons I do not understand, Stanford, Berkeley, and CMU have taken the time to sign as well. And that's it.
(For others reading: you can take a list of domains and do a quick spot check for DNS by just running "host -t ds (domain)".)
Note that cloud.gov is FedRAMP-authorized and does not itself support DNSSEC, which I point out in addition to the rationale cloud.gov provides on that link (which answers your direct question).
The root issue (pun not intended) is that DNS is not fully encrypted, not even point-to-point, DNSSEC only provides an integrity check, no encryption; DoT/DoH is only used between a resolver and a client as a last-mile solution. No robust security can be derived from the absence of full encryption - there is none, ultimately the traffic is sent in clear over the Internet backbone. You must make your own choice of trust for sending traffic in cleartext - your local network at home/school/hotel, your rented VPS provider, your ISP, or Google/CloudFlare.
Given that CloudFlare already has 13%+ market share, as an end-user, if my primary threat is eavesdropping in the middle, not eavesdropping by CloudFlare (or by NSA's subpoena or NSL), it's actually reasonable to trust the tech giants. Using CloudFlare's DoH server helps me to end-to-end encrypt my query of 13% of the domain names! Also, CloudFlare has business plan to adopt private encrypted DNS links to other authoritative servers, and they already have a private channel with Facebook, it's even better! Don't start sending hate replies, I know the bigger picture is that it allows CloudFlare to effectively monopolize DNS is extremely harmful in the long run, and I'm worried. But I simply don't see a perfect alternative solution that allows one to self-host a resolver at home with end-to-end encryption to communicate with authoritative servers.
You see, the end results that everyone should work towards is introducing encryption to the missing resolver-authoritative server link.
DNSCurve was developed in 2005 as a practical and high-performance protocol for deployment on authoritative servers, and fill the missing link, the protocol is great, DNSCrypt was its direct descendant for last-mile client-resolver encryption.
It was ultimately not adopted, partially because of many hate DJB's personal style of taking an aggressive position over technical issue, especially his attack on DNSSEC. But also, the final reason was that the ICANN has stated that, in the case of the DNS Root zone servers, DNSCurve will never ever be implemented. First because its threat model doesn't include the authoritative servers themselves, and it gives them the private key. This is fine for private use, but the DNS root servers are controlled by many political entities, and ICANN doesn't believe trusting them is acceptable. DNSSEC was designed in a way to avoid giving the ultimate key to root servers, but not DNSCurve. Also, DJB hated DNSSEC so much that DNSSEC cannot be used to sign the pubkey for DNSCurve resolver - oops!
In the future, we should work toward a solution for resolver-authoritative server encryption. In the article, the author mentioned DNS-over-TLS is a potential solution, if so, we should push to deploy DNS-over-TLS on major authoritative servers, or perhaps one day, on the root servers if a solution has been worked out.
Only then, it could allow us to say farewell to CloudFlare's DNS and Google's DoH resolvers.
This is a great summary and I agree with the findings mostly. I think we should separate the "DoH the protocol" from the "DoH decision of using a public resolver". For "DoH the protocol", widespread adoption by most users' default resolvers is about as likely as widespread adoption of DNSSEC and DoT. For "DoH decision of using a public resolver", that decision can be done today with resolvers that support DNSSEC/DoT.
So if we want users to use a hardcoded default resolver different than their ISP's, come out and say that and stop conflating it w/ the protocol. If we want users to use the DoH protocol, we're in the same boat as asking them to use DNSSEC/DoT. Therefore, for the idea of a hardcoded default resolver in one browser, if it's really something a browser wants to do, why are they waiting on a protocol? And for the idea in another browser of checking known protocol support of the existing resolver, do/can they do that with DoT too? And can they do something besides a hardcoded list to check resolver capabilities (i.e. can I return an additional record/bit from my DNS servers that is essentially DNS equivalent of HTTP Alt-Svc to say I support DoH)?
The entire premise of DoH and DoT are that you don't want to use your ISP's DNS. Nobody needs to "come out and say that"; it's whole point. They're both mechanisms to tunnel DNS out of your network to somewhere safer. The difference between the two is that DoT has a network-operator kill switch, and DoH doesn't.
> The entire premise of DoH and DoT are that you don't want to use your ISP's DNS
This is the discussion separation I am requesting. There is benefit of in-transit encryption regardless of who the endpoint is. There may also be benefits to defaulting to non-system DNS, but those discussions should be separate IMO.
What's the benefit of encrypting your DNS traffic to the ISP? There isn't anyone between otherwise they'd be your ISP. The point of DoH is to provide a way to configure DNS to something that isn't the ISP without the ISP being able to block it, snoop it, or intercept it. There is no separating the concept because if you're doing it to the ISP then the reasons for doing it are now invalid.
Also "not the ISP" != "non-system dns". Don't conflate that just because browsers were first/most famous to implement.
I specifically said endpoints and not ISP because the proliferation of encrypted DNS traffic is a good thing regardless. Also, there is still MITM potential between you and your ISP's DNS server as many ISPs share pipes that have been known to be tapped at different PoPs. The value of encryption to DNS servers is obvious, even if we pretended that user-to-ISP traffic was all we were talking about.
I liken these arguments to the same ones made in the past by our more-naive selves concerning encryption of corporate intranet traffic. We should be smarter now.
Replace ISP with endpoint, the conversation is the same. Simply encrypting to whatever the other end of the cable tells you to is false security. If the other end of the cable is malicious it will just lie about what your DoH server is. You can establish identity with a CA infrastructure and a precoded default destination, this is what DoH is about
Encrypting traffic, internal or external, only makes sense if you don't trust whatever you happen to plug in to tell you what to trust. OWE in Wi-Fi has similar faults.
Using someone's resolver other than your own is sensible: it serves to hide from authoritative servers the IP addresses of each query's requestor, both because the resolver aggregates many clients' lookups, and because of caching.
But whoever runs the resolver you use gets to see what domainnames you're resolving. Your resolver's operator will be sorely tempted to monetize that metadata.
Your only choice is which resolver operator you'll allow to monetize your metadata.
So you lose no matter what, unless you have a contract with the operator, and then you'd better be giving them something of value if you want to be able to enforce the contract's confidentiality requirements.
ISPs mostly don't even support DoH/DoT, which is a reason to not want to use their resolvers. But using public resolvers helps centralize the DNS, which is not good.
Yes. If you're concerned that your third-party resolver is monetizing or otherwise monitoring your DNS, you can run your own DoH recursor, semi-anonymously, from a public cloud account. In the long run, presumably trustworthy organizations will stand up DoH resolvers that people can trust.
I preemptively agree that Cloud Flare is not one of those organizations.
It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.
> It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.
Perhaps a parent wants something that's easier to filter.
Paul Vixie has said a lot on this topic.
Yes; Paul Vixie is to DoH what I am to DNSSEC, and his consistent case is "DoH is bad because it's hard for network operators to turn it off for users". To me, that's a ringing endorsement.
> To me, that's a ringing endorsement.
And to me, who works in IT, it's a bloody annoying.
We've already implemented the use-application-dns.net NXDOMAIN canary at work because after some testing Firefox breaks a bunch of apps because of split-horizon DNS.
There's already (at least) two malware that's using DoH to get around network monitoring:
* https://www.zdnet.com/article/first-ever-malware-strain-spot...
* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...
If the host is compromised we can no longer trust end-point monitoring, and with DoH/ESNI we lose network monitoring. Awesome. Great work.
I absolutely understand why it's bloody annoying for network operators. What I don't understand is why any home user should trade even the tiniest iota of their privacy to make your life any easier. You get paid to deal with these problems.
In certain situations, even home users are in the same position as network operators. The processes running on their machines will use exactly these same mechanisms to escape the user control. The last few years have shown, that big brand names are not to be trusted, and their interests, as implemented in their software, are not aligned with user interests. In a way, we are getting back full-circle to Stallman.
DoH+ESNI will make it even harder.
I don't understand whether you're saying that DoH+ESNI will make it harder for malicious network operators to compromise user privacy (clearly true) or whether DoH+ESNI will make it harder for home users to run their networks as if they were enterprise networks.
It would be a genuinely weird new take to argue that encrypted SNI was somehow harmful to privacy.
> It would be a genuinely weird new take to argue that encrypted SNI was somehow harmful to privacy.
As a 'network operator' at work and home, it is my responsibility to keep my network clean. Both for my own sake and for the sake of the greater Internet (is malware being spread from my network?).
End-host security is used to make sure that connected systems are clean. But if the end-host is compromised, then that may now become useless. So a second level of security is network monitoring.
However, how can I be responsible network operator if I have no visibility into my own infrastructure? DoH by-passing local DNS, and ESNI cloaking the destinations, make it impossible to see who is doing what. At least with Do53 (and DoT) I can control lookups (possibly to C&C servers).
What is privacy? The same way the home user can get privacy from the network operator, can malware get its privacy from the home user.
This is amplified by moving DNS resolution into applications, Mozilla style. Now even the operating system or local firewall applications (Little Snitch, etc) can't know, where the processes are connecting.
Again, the application vendors can have objectives that are not aligned with the users. It is a mistake to conflate the home users with random applications running on their computers.
This argument doesn't make any sense. TLS SNI hostnames should remain unencrypted to help user privacy?
No.
The argument is, that a random process should not be a world into itself; there should be a way to check on what it is doing. It does not have to be network based, it can be done by another process on the local machine. Things like DNS should be done by the OS, with hooks for the monitoring. It should be not be done by the application, with zero transparency to the owner. The system resolver, on the other hand, can use DoH/DoT/ESNI/whatever.
Giving random processes unlimited, uncontrolled and uncontrollable access to Internet is disaster waiting to happen. Quite similar to what happened to applications on Android.
What does the system resolver have to do with encrypting TLS SNI?
With the privacy.
I don't know, whether I'm expressing badly due to English not being my native language, or where is the problem in understanding. I hope that you are not just misunderstanding intentionally.
So once again: The combination of ESNI and DNS resolving inside applications (and not OS, not checked by some user agent) provides privacy to application, not users. That application might or might not have its objectives aligned with the users; more often than not, it will focus on interests of its vendor instead. So conflating privacy for application with privacy for user is mistake.
By applications using custom DNS+ESNI, the user loses control over who the application communicates with, he just sees that it can send and receive blobs. What it is sending out, to whom, is and will be unknown. That is the negative wrt user's privacy, compared to which the current Android ecosystem is squeaky clean.
If you were counting on DNS and SNI monitoring to detect compromised endpoints, you’ve lost anyways, because malware can chose its own dns resolution method and avoid SNI regardless of what the OS or Firefox are set up to do.
Even better, Malware can (popular malware doesn't so far as I can see today, but could if other methods stopped working) straight up lie in SNI and in the old TLS 1.2 plaintext Certificate message, and produce plausible yet entirely misleading results in your inspection apparatus.
A real client expects the encrypted parts that follow Certificate to match up and should abort if they don't, but malware is under no obligation to do that, and a 3rd party which can't decrypt the rest of the handshake won't know e.g.
Malware client: SNI for bigbank.example (knowing bigbank will have been excluded from snooping rules at the target)
Malware C&C server: 100% Legitimate Certificate copied from bigbank.example
Malware client: Cool, let's continue with encrypted setup (ignores the pretence that this is bigbank.example and now communicates with the C&C server undetected and encrypted knowing the logs will just show "bigbank.example")
"Security" products can't protect against this without snooping each and every single transaction, but many will be deployed by ignorant/ well-meaning people who don't understand how this works and thus that the products can't actually do what they appear to offer to do.
> ... because malware can chose its own dns resolution method ...
Except before DoH I could monitor DNS: with plain DNS ("Do53") it is completely visible, and with DoT it is on a different port so it can be filtered.
Which is Paul Vixie's point: DoH takes control away from network owners, like me and my home Asus, and me and work.
Yes, but the malware isn't required to use port 53 or "plain DNS" at all...
Regardless of what the OS or Firefox or whatever existing app uses, a malicious binary could just use DoH, or just make an HTTP request directly to an IP, or skip HTTP/DNS entirely and fling data out over UDP to an external IP.
Put another way: if your issue is that DoH removes your ability to catch DNS requests from malware, your issue isn't with users enabling DoH, or with app devs defaulting their apps to DoH, your issue is with the concept of non-DNS network protocols. Even if DoH was never standardized, an attacker isn't required to make lookups on port 53 as you desire.
> I preemptively agree that Cloud Flare is not one of those organizations.
Would you please elaborate on your distrust of Cloudflare? I’m not looking to call you out. Quite the opposite, I appreciate your candor. I just feel like I’m missing some context.
I'm not comfortable getting into it here. Just suffice it to say that my support for DoH has absolutely nothing to do with Cloud Flare's support for it.
We all should be worried about loss of privacy, but we can't all run our own resolvers on the cloud.
The choice of DoT vs DoH will mostly be about what is supported by one's choice of resolver. Of course, choosing DoH first will narrow the choice of resolvers.
Then there's captive portal situations.
This is a false controversy. The people that "can't" run their own resolvers are, overwhelmingly, using their ISP's resolvers. At least in the US, all of those ISPs are actively attacking their users. Users are better off using practically any other mainstream centralized DNS provider than their ISP default.
But this isn't a stable equilibrium; as I said, it seems clear that privacy-minded organizations will eventually stand up their own trustworthy DoH resolvers.
DoH makes things somewhat better today for all users, and much better for power users. In the long term, it's easy to see how DoH makes things much better for everybody.
Running one's own recursor using DNSSEC via an ISP's resolver (for the privacy benefit relative to authoritatives) would take care of active attacks by ISPs on their users. Windows and Linux could do this you know, but security would be enhanced only relative to sites that use DNSSEC.
But I don't disagree that DoH is better.
I do hope that in the long run ISPs become less toxic.
Running one's own resolver with DNSSEC would do absolutely nothing about the ISP threat, since DNSSEC is a cleartext signing-only protocol. Since the overwhelming majority of zones aren't signed, it won't even protect you from the garish NXDOMAIN landing page attack.
I was referring to active attacks. I don't consider an ISP or a public resolver operator to be particularly different w.r.t. passive attacks: both get to do it, and both do do it.
Do you think quad9[0] is a trustworthy organization?
[0]: https://www.quad9.net
Tricky question. I'm the chairman of Quad9's board of directors. So _I_ trust the organization. But I'd urge everyone else not to trust _any_ organization, but instead to do as much to protect yourself as possible, using an external recursive resolver only when you need to.
That means running your own caching resolver, with a local copy of the root zone and QNAME minimization enabled, and then using DNS-over-TLS to forward the minimum necessary query onward.
The next question then becomes whether to perform recursion yourself (by talking directly with authoritative nameservers) or to have Quad9 or another recursive server perform the recursion for you. Authoritative nameservers don't yet support transport encryption, though we're working very hard to support it on the 500 TLDs PCH is authoritative for, and Verisign is working very hard to support it on .COM and .NET. So that means that your traffic is subject to interception, and essentially all authoritative servers either log queries or have people logging queries off the wire in front of them. And if you're handling your own recursion, everything you don't have cached crosses the wire, and none of it is blended together with anyone else's traffic.
To make the decision as to whether it's better to trust a recursive or send queries directly, knowing something about the practices and purpose of the recursive is necessary. Quad9 is the only major recursive that's a public-benefit not-for-profit. There are other small ones which are not-for-profits (like the Taiwanese 101.101.101.101, operated by TWNIC), but all of the others that come near Quad9's scale or traffic are for-profit, operated by companies that monetize data. Quad9 and Cisco's commercial Umbrella service are the only two which are GDPR-compliant and thus legal to provide to European citizens.
Quad9 exists solely so that bad choices won't be the only choices.
> The entire premise of DoH and DoT are that you don't want to use your ISP's DNS.
One's ISP could be a mobile telco: I could trust the telco more that I trust the security of GSM/3G/LTE.
Also: does my ISP use Huawei equipment? I could trust my ISP's servers more than their network gear. :) Ask the IT folks at the Africa Union HQ:
* https://en.wikipedia.org/wiki/AU_Conference_Center_and_Offic...
The major difference between DoH and DoT is that DoH is a proxy while DoT is end-to-end. With DoH we assume that the client connects to the central DoH server and beyond that there is dragon. There is no such design in DoT and the resolver is set to independent create DoT connection to all other resolvers in the chain.
If we are concerned with kill switches, the end-to-end design is less fragile to malicious and legal attacks than a proxy scheme with a handful of operators.
That is entirely wrong. My implementation of DoH and DoT (running in production at the University of Cambridge) uses nginx as a proxy for both protocols in front of our normal recursive DNS servers. DoT is widely used by Android devices on our wireless network; DoH is only being used by a small number of lunatics such as me.
https://github.com/fanf2/doh101
https://www.dns.cam.ac.uk/servers/doth.html
I have never heard anyone propose that DoH should be running in front of authoritative resolvers. DoH is strictly a recursive DNS feature where the client contact the recursive resolver and the recursive resolver on the behalf on the client goes and gather the answers to the query. People can disagree on the terminology here but I call that a proxy.
With DoT there is little reasons to not apply the same technology to authoritative resolvers. Conceptually it is almost as simple as supporting both UDP and TCP, and with the low number of root authoritative servers you can even store locally the address and certificates as part of the operating system. Since a lot of TLDs already have signed roots for DNSSEC it is even a pretty simple move forward to imagine a TLS support being enabled by them and the root. I would be amiss to not mention that Bind already store address and root zone keys of root servers as part of the install package.
A bit of a tell is that there is an RFC for authoritative servers running DoT. It is called aDoT. There is no RFC for DoH, and no one is talking about aDoH. Authoritative servers running DoH is not on the map, but aDoT is. Again we can disagree on the terminology but this is the reason why I see DoH as primary a security tool for proxying DNS request while DoT can be used for end-to-end.
I think you are very confused about the maturity of authoritative DoT.
Have a look at https://datatracker.ietf.org/wg/dprive/documents/
None of the authoritative DoT drafts have even been adopted by a working group yet, so based on the usual IETF timescales means they are probably years away from an RFC.
There are still substantial problems to be worked out wrt working out if an auth server supports DoT without slowing things down horribly, and working out how to authenticate a server without getting mired in EPP and the ICANN/registry/registrar policy swamp. The threat model needs to be clarified: do we need to protect against active attacks (much more difficult and stronger authentication required) or just passive snooping (which allows opportunistic upgrade). Does TOFU make sense?
So many questions still to be resolved, as it were
That was a bit unnecessary hostile.
The idea that communication between resolver and authoritative servers should be encrypted is not a new concept. People have been discussing and talking about it for, I would like to say decades. What it does not have is an opportunity for data collection and there is not multiple companies competing to become the central location for dns query data. There is no default setting which a company might pay a significant sum for. Like DNSSEC there is also very little to be gained by authoritative DNS server providers in return for any added complexity. Since I work in this industry I can with fair confidence say that for most registrars the added risk and complexity is the primary reason why security technology in the DNS space is not moving like it does in other areas.
It used to be the same thing for email servers but googles attitude more or less changed that. If you do not support TLS then google is more likely to mark your email as spam. The cost of installing TLS is significant smaller than the cost of users email getting flagged as spam, so within a very short time window most email providers suddenly started to support TLS. Getting people to care about security is often a simple matter between risk and cost, a fact often brought up by Bruce Schneier.
> Does TOFU make sense
There is many potential schemes but one of the more simpler one would be to use DNSSEC and hardcode the certificates of the root servers (Authoritive server programs already hardcode some information about root servers as they rarely change). About 1398 of 1527 TLDs have signed zone in dnssec and it would cover most lookup. In theory there is nothing to prevent the root server from simply publishing TLS keys next to the NS records, with registries doing the same. Looking at how communication between email servers became TLS protected, they did not resolve all those questions and yet we went from all plaintext to almost all encrypted in a few years.
As side note, let me give one example of a business concept. When you buy a domain there is usually a way to get analytics of how the domain get queried. Information like how often and from where which helps the domain owner get a perspective of how their domain get used. Let now say 80% of the traffic get routed through cloudflare. 80% of the logs are now gone. That is sad but you can buy it back If you move your DNS to cloudflare which will happy provide analytic for your domain. All Pro, Business and Enterprise plan customers will even get additional geographical information.
I don’t mean to be hostile, I just want to make it clear that it is wrong to say “DoT is end-to-end” and wrong to say “there is an RFC for authoritative servers running DoT”. It might possibly happen at some point in the future but there is a lot of work still to do before then.
The reason aDoT exist is that DoT was written under a specific charter. To quote the RFC 7858: It might work equally between recursive clients and authoritative servers, but this application of the protocol is out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per its current charter.
There is nothing inherent of the DoT protocol that forces a model of client->recursive->authoritative. The RFC is pretty light on even mentioning recursive. It mention a technical aspect of recursive client in exactly one place, which is when discussing connection reuse for multiple requests by saying it should (not must) reuse TCP connection if possible. The RFC really just boils down to the concept of applying TLS to a tcp and udp based protocol.
The DoH RFC 8484 is very different and as mentioned above there is no one who is suggesting to apply it in any form beyond as a technology between stub resolver and a recursive server.
The dns-privacy IETF is quite relevant in context. If we want to be technically correct here, there is a draft RFC for authoritative servers running DoT called aDoT, with DANE as authentication.
Lets imagine a DoH protocol for email where Google or Microsoft suggest that email client should ignore smtp setting and send all email to them by default, and compare that to current model that we use today where client talk securely to servers and server talk security between each other. When viewed like that, is it unfair to describe DoH as being a proxy and the model of just adding TLS as being end-to-end?
There's a tension between using private, semi-public (ISP-run), and public resolvers.
The more clients a resolver has, the better the privacy protection it offers vis-a-vis authoritative servers, so there's some reason to want to use one's ISP's resolver, or even a public resolver.
On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data.
Regardless, ISPs need to adopt support for DoT and DoH.
Lastly, it'd be nice if we could get authoritative servers to support DoT/DoH, but that will take a long time.
It'd have been nice to have settled on DNSCurve for confidentiality a decade ago... Even assuming Curve25519's eventual obsolescence, it would have served us well while waiting for a better solution.
> On the other hand, you may not want your ISP to know about some of the sites you visit, or you may not want a public resolver operator to know. After all, both will have a huge incentive to monetize that data.
To be clear here, your ISP will still know what sites you visit, unless you are using a VPN. There are two vectors for them to gather this information: 1) the IPs are generally pretty stable for most sites (yes that could host many web sites, but still), 2) The SNI is will be sent in the clear for the website to be able to choose the correct certificate for the connection.
That's not to say that there isn't value in DoH/DoT, there still is, but your ISP is still going to be able to follow you around the web pretty easily.
They'll know the IP addresses, but unless the DPI the SNIs, they may not know the domainnames, especially when an IP serves multiple domains.
I disagree with the usage of DPI here like it's a significant barrier. Your ISP has access to both the IPs and the SNIs. They can dedicate resources to log them or not to. SNI requires only a little bit more processing power, but otherwise they "know" both.
This work is landing in parallel with development of eSNI, encrypted SNI.
If you have a Firefox with this stuff switched on (so it uses TLS 1.3, eSNI and uses CloudFlare's DoH server), and you go to a site that's proxied by CloudFlare, only CloudFlare [and the site] know which site that was, an ISP sees only that you connected to CloudFlare (duh) and did some HTTPS transactions.
There will be SNI in the ClientHello, but it's generic, it doesn't say which CloudFlare service you wanted so it doesn't help an ISP to log that. The IP belongs to CloudFlare so they learn that, but the rest is a mystery.
All the stuff that makes this go lives in DNS. For privacy you should use DoH to go fetch it. For authenticity you should use DNSSEC to verify it. Proposals are under development for how to land the final DNS changes with HTTP/3 in there as well, so that a single query protected by DoH + DNSSEC can tell a browser "For HTTPS speak QUIC on this IP address and send this fake SNI, then use this eSNI encryption key to hide the real hostname".
But already the prototype with boring TLS 1.3 and HTTP/2 works just fine in Firefox builds with it enabled.
I'm really looking forward to tls1.3, but there's still a bit of time before it gets widely adopted. CloudFlare proxy will help a lot where they handle the connection, but there's lots of services which will take years to upgrade.
It'd be nice if we could settle on DNSCurve for authoritative servers even now. It's significantly simpler and more efficient than DoH and the only real advantage DoH has over it (less interference from quarrelsome middleboxes) isn't nearly the problem between recursive and authoritative resolvers as it is between clients and recursive resolvers, because recursive resolvers are almost always operated from networks that are responsive to their administrators.
Why do you say DNSCurve is simpler? Having implemented DoH and DoT, it's pretty much as simple as adding TLS to the connection...
It's simple if you pull in a dependency on a library that does it for you, but that's just putting the complexity in the library. HTTP is a complex protocol, TLS is a complex protocol, even just using TCP isn't exactly simple or advantageous to response latency.
TLS is a complex protocol with trusted mainstream implementations (even OpenSSL, at this point, is a fine option).
Trusted mainstream implementations come from use. You might get the same number of vulnerabilities from a green new DNSCurve library as from old battered OpenSSL because you're trading off the protocol complexity against the years of grinding away at all the bugs, but that only gets you to parity. Which itself only lasts until the DNSCurve library is trusted and mainstream and claims the advantage because the younger code matures but the protocol stays simpler.
In the meantime DoH still has worse latency because of the extra round trips. Especially in the authoritative case where you're typically making few queries each to many authoritative servers instead of making many queries to one recursive resolver and you can't reuse the one handshake for all your queries.
> TLS is a complex protocol with trusted mainstream implementations (even OpenSSL, at this point, is a fine option).
Trusted for now.
How long until the next heartbleed? Do you want that vulnerability embedded in billions of unupdatable IoT-devices?
Personally I trust much more the authoritative root servers than public resolver. The root servers economic model is being the backbone of the Internet, they are not advertisement companies, they have a long history of working as an infrastructure, and there is very little incentive to monetize that data. The risk of a fork in the DNS system has always been the sword that kept the authoritative root servers honest.
If authoritative root servers started to support DoT/DoH/DNSCurve then clients could do secure end-to-end communication with simple two hops in the vast majority of cases. In the case of news.ycombinator.com it would ask .com for ycombinator without informing the TLD server of the remaining parts of the domain, and then ask ycombinator.com for news. Simple end-to-end communication without giving out unnecessary information to any party.
I’ve always heard that the root servers are not capable of handling that amount of load. Is this no longer a major concern?
I have asked that question a few times in conferences. Capacity wise they can handle it as they already need it to defend against the massive DDoS threat that they face. Relative recently they also added anycast, which further increases the capacity.
DNS queries is also generally quite small and has not significant changed, and the modern resolver software is pretty efficient. DNS is also designed for redundancy so in combination with anycast is quite simply to scale up.
Because of the persistent DDoS threat the question of capacity is constantly discussed. I don't remember the exact numbers but the current overhead is quite large compared to actual usage. It is also constantly being increased based on the threat rather than usage.
Great point. I don’t mind improved DNS security.
DoH the protocol, being based on HTTP feels wrong, but I guess that’s how the kids these days writes protocols. So be it.
DoH, the resolver, being chosen for me, without my consent... that’s an absolute no go. That’s what malware does.
Did you choose your DNS resolver?
Yes. Through lots of actions: By choosing ISP. By setting up my own router. By implementing a pihole. By configuring my OS.
No application has any business overriding any of those choices unasked, but should use what the OS provides.
Like every application does, except modern browsers which for some reason think they are special.
Here’s news for you: they’re not.
I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser.
Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites?
> I don't really understand how you gave your consent any more explicitly in that case than I did when I chose and configured Firefox as my browser.
That's not a reasonable position. Never before in the history of computing has a regular end-user application actively tried to subvert the operating-system's network defaults.
Why should anyone expect that to be the position now? Should I expect Thunderbird too to bypass my DNS-settings? What about Rust's cargo? It's from Mozilla too.
Will I need to manually go configure all those tools to do what is the reasonable default, namely following what the OS tells it to do?
When Firefox fails to resolve a domain, but nslookup resolves it just fine... What should I as an end-user believe? (Besides that we have an orderly world turning into chaos)
Do you really think every application choosing, managing and implementing its own resolver is a scalable way of managing applications and networking? Really? Yeah no. So why should browsers get a free pass do things differently?
> Did your ISP make it explicitly clear to you upon signing up that with the default configuration, they'd be able to see all domain names you visit including of encrypted websites?
No. But that's not what we're talking about here.
What has always been a clear expectation is that if I sign up for an ISP and I use that ISP's default network setup, that I will be using that ISP's DNS. Never in the history of ISPs has there been any other default.
So if I may rephrase your question:
> Was it explicitly clear to you that by using an ISP as an ISP, you will also by default use their DNS services?
Obviously. That's how the internet works and has always worked. In fact, anything else would be strange.
Unless I explicitly implement something differently, I have no reason to expect anyone besides my ISP (which I do trust, I'm not from the US) is handling my DNS.
Unlike my ISP (which I trust), anyone who deviates from this contract will be someone I actively distrust. I'm looking at you, Mozilla.
> What about Rust's cargo? It's from Mozilla too.
Mozilla does not have this kind of influence over Rust. They've never indicated that they'd want us to do this, we've never thought that doing this is something we'd want to do, but if they told us they wanted it, and we didn't want it, it wouldn't happen.
> That's not a reasonable position. Never before in the history of computing has a regular end-user application actively tried to subvert the operating-system's network defaults. ... Will I need to manually go configure all those tools to do what is the reasonable default, namely following what the OS tells it to do?
For starters, just because the OS provides its own name resolving facilities doesn't mean it's telling applications to use it. It's there to make application development easier, not as a security feature.
> When Firefox fails to resolve a domain, but nslookup resolves it just fine... What should I as an end-user believe?
The end user should believe what the error message says, because we don't design web browsers with the expectation that the user understands how DNS works. And if they do, then I don't see why it's so onerous to ask that they also learn how DoH works, given that having that default is in the best interest of the majority of the product's users.
> Do you really think every application choosing, managing and implementing its own resolver is a scalable way of managing applications and networking? ... So why should browsers get a free pass do things differently?
Yes, I don't really see how that's such a big scalability problem like you're making it out to be. It is obviously necessary that any networked application will manage and implement its own purpose-built network protocol already. That is a significant amount of complexity necessary to any networked application, and name resolution is just a small function in comparison.
Furthermore it actually does make sense for web browsers to have special behaviour here since they are almost never used to connect to LAN resources, just internet resources, which is unlike many other networked applications. They also make up a widely used application platform which has specific security and privacy needs that other networked applications don't have.
> No. But that's not what we're talking about here.
It's what I'm talking about, because I don't see how to make sense of your "Firefox is malware" analogy otherwise. Your ISP picked a default, Mozilla picked a different default.
> What has always been a clear expectation is that if I sign up for an ISP and I use that ISP's default network setup, that I will be using that ISP's DNS. Never in the history of ISPs has there been any other default. ... Unless I explicitly implement something differently, I have no reason to expect anyone besides my ISP (which I do trust, I'm not from the US) is handling my DNS.
I don't think that's a clear expectation to most of the people who are in fact sold internet access without being trained on how DNS works. I also believe that Mozilla very clearly communicated that they were changing this default, through many channels, to Firefox users. So your implication that Mozilla is doing something sneaky here is ridiculous.
I'm sorry that this change broke your PiHole config but you can fix it easily. New software sometimes breaks your old configs. That's life. If you want an ad-blocking solution that isn't so brittle, then try installing uBO on the client rather than abusing DNS for that purpose.
It didn’t break my setup as much as it broke my trust.
Now I have my entire network set to hunt down and kill any attempt of DoH and IP-ban all known resolvers.
Just because we can’t trust even (formerly) respectable software vendors to respect the user’s network.
Is that what you guys want? Because that is what going rogue like you do is going to get you.
Great summary. The user's threat model could be more succinct and address the question of what the end user is really protecting, and from whom. Then the features of the different protocols would be mitigations to that risk.
I've got a horse in the race, but I might use it as an example input for the method in this post: https://www.qtra.io/simpletm
Short version would be, <end user> wants to protect the <confidentiality and integrity> of the <contents of their browsing history> from:
<isps> who <using it to target ads and sell to 3rd parties>
<intelligence agencies> who <are engaged in bulk collection>
<employers> who <use browsing history as leverage to manage out staff.>
etc.
We need the who, why, and what, before the how. Excellent summary all around though.
Great discussion. I also think that the more we talk about it, the more and better solutions will start appearing to solve all the problems that come with choosing DNS providers. There is also one issue that we don't discuss too much. I understand that by selecting a private DNS resolver over the ISPs DNS, you still provide your info to that resolver's operator, and they can monetize it. And here I see one crucial thing - choosing the provider that HAS to collect your data over choosing the provider that doesn't do it. Correct me if I'm wrong, but basically, any DNS provider located in the USA is required to collect and store your data by law. So it's not only easy to use that data for monetization, but also they would be required to give all that info to the gov if needed. I was going through a list of most popular DNS providers, and I didn't quite like what I saw. But I found this Trust DNS app (https://surfshark.com/trust-dns) that as a product from Surfshark is also located in the British Virgin Islands. So technically, they are not required to collect any users' data, and they state that they don't. There is also an option to switch between DoH and DoT. The only downside is that it's only for Android right now. Any thoughts about it? Are there more options that are not based in the USA or other 14 eyes countries (or well, China)?
More attention needs to be paid to QName minimization, IMO.
DNSSEC is the only truly hierarchical PKI with pervasive name constraints that we have. That makes it very valuable, even if it is difficult to leverage to solve other problems.
Like all PKIs, DNSSEC is vulnerable to authorities (that is, authoritative servers) acting as MITMs. WebPKI makes it very easy for nation states to acquire MITM credentials: just subvert a national CA and you're done because the WebPKI lacks name constraints. A real PKI makes this harder, because a nation state can only legally subvert authorities within its jurisdiction.
The root zone is special though, as long as there is only one, and that's why the root zone operators make such a special show of key signing events: to increase confidence that it has not been subverted. But the root zone is still a concern -- if not today, then tomorrow.
Enter QName minimization. By sending minimized queries -at the cost of having to do more queries, thus having higher latency- one can keep intermediate authorities from observing the full domainname that one is attempting to resolve. That makes is more difficult for authorities to MITM specific targets.
The opposite claim is closer to the truth regarding "true hierarchical PKIs" versus the WebPKI. In reality, if a state suborns a CA to misissue certificates, Mozilla and Chromium will nuke that CA from orbit. You don't have to wonder about this; Mozilla and Chromium casually destroyed some of the largest commercial CAs. Moreover, misissuance is very likely to be detected, because Chromium and Mozilla have moved towards requiring Certificate Transparency participation.
On the other hand, if a state suborns its DNS providers to inject bogus keys, there is no recourse. You can't revoke .COM. Is Google going to become Google.IO? Wait, no, .IO is controlled by Five Eyes as well.
> Mozilla and Chromium casually destroyed some of the largest commercial CAs
While I agree with much of your comment, I think you are doing both Google and Mozilla a disservice to say they did this "casually". The decisions to distrust the CAs in question were not taken lightly; they came after repeat offences, and the grounds for doing so were abundantly clear.
I don't buy that.
First, we see that China, for example, has enormous market power that it uses to get its way in just about every controversy.
Second, CAs will get kicked off the TA list only if they get caught.
I addressed that in my comment: it's never been easier to get caught, since certificate issuance is now cryptographically logged.
It's also possible for a state to suborn a registrar to publish a fraudulent record so that the state can get a DV cert issued by the CA of its choosing. This leaves the WebPKI in no better shape than DNSSEC + CT when it comes to state level attackers obtaining fraudulent certifications.
This is of course why DNSSEC is crucial anyway. DNS is the foundation under the Web PKI, a secure Web PKI on top of insecure DNS doesn't buy you very much. It's impressive we've got this far in fact.
It was most fun in the old days, before the Ten Blessed Methods. You'd get this contrast between the wild imaginations of anti-DNSSEC people who imagined every certificate application is investigated by some combination of Jason Bourne and Sherlock Holmes - and a reality where it's just somebody got a blurry fax from a law firm in another country and so they pressed OK because everybody knows lawyers are honest.
I don't know what you're on about with this "Sherlock Holmes" stuff, but the last several CA kill-shots occurred after Google and Mozilla detected misissuances. And Google and Mozilla didn't just revoke the certificates: they killed the CAs themselves.
Are you not watching CT logs for domains you work on?
As you definitely ought to know if you had any idea about this topic I run a complete Log Monitor for my employer these days and so in that sense I am watching all of the public logs.
I also run smaller monitors and auditors for my own interest as an active participant in m.d.s.policy. Which is why it's always weird to hear your version of what goes on there, since you don't participate and seem to base your understanding on something like a tabloid newspaper report or a Hollywood script rather than the reality.
I don't post on m.d.s.policy or any other standards or community organizations, both because I think all of these sewing-circle groups are a net-negative for security (we'd be better off just letting Ryan Sleevi call the shots), and because not a single one of them them would be better off if I was there mouthing off. I feel like more people --- I can name specific people --- should consider following my lead on this and getting the fuck out of the way on task-oriented forums. There's plenty of other places --- like HN --- to say what I think, and synthesize what I've learned from other people.
Don't mistake any of that for me not keeping up with these groups. Your arguments still have to make sense to succeed; you do not in fact have an "I post on m.d.s.policy" card to play here.
> From my perspective, I believe that we should work on pushing for wider adoption of DNSSEC, because I continue to come back to the core problem of DNS results not being authenticated or verified.
Can we replace DNSSEC with something that doesn't give government control over root zones?
I suppose you could have blockchain DNSes. Indeed, attempts have been made. Of course, then you get the same problems as with cryptographic coins, where getting 51% of mining resources lets you double-spend, which for DNS would mean letting you MITM specific targets. And guess what governments would do about that?
Repeat after me: rubber hose cryptanalysis is unbeatable / cryptography cannot solve political problems.
This comes to mind: https://sockpuppet.org/blog/2015/01/15/against-dnssec/
Very yes. `tptacek has great takes on DNSSEC
tptacek has a tendency to deny the existence of problems that he doesn't consider to be important, and thus his criticism of DNSSEC tends to go a little bit too far. He does a great job of explaining what's wrong with DNSSEC and I agree with the general conclusion that it's not worth the trouble, but his blindspots are a bit annoying.
What in particular are you referring to?
Feel free to provide an example!
Not OP, but in particular one of the major points of your post about the issues surrounding DNSSEC is that TLDs are controlled ultimately by the government with jurisdiction over them. Specifically I'm talking about the section titled "DNSSEC is a Government-Controlled PKI". You present the argument that the existing CA system is more protected from government interference than registrars. I think that argument is pretty weak considering that for the most part we're just talking about DV certificates and all a DV certificate from a CA signifies is that that particular CA verified that the entity they issued the certificate to controlled that domain. When ICE seizes a domain name, they can get a DV certificate no problem, they own the domain at that point. If Muammar Gaddafi ordered bit.ly to be seized for some hypothetical "Bureau of Information Technology", he could have absolutely gone to any CA afterwards and gotten a DV certificate.
Why should a litany of CAs with authority to sign certificates for largely any TLD be preferable to only allow the entity that's authoritative on domain ownership being able to sign valid certificates? DV certs are just indirectly checking with DNS anyways and there are pitfalls in that process and no real benefits in the end.
Google and Mozilla can (and likely would) destroy the CA that allowed an unauthorized Gmail.com (not DNSSEC-signed, by the way) certificate to be issued. They have destroyed some of the largest commercial CAs in the industry for less.
Neither Google nor Mozilla can revoke .COM, and the USG has repeatedly used its authority over .COM for public policy ends.
Yet they haven't, and never will remove CAs that sign certificates for domains that ICE has seized. If the US government actually took the extraordinary step of just flat out taking ownership of gmail.com under the guise of some anti-trust action then they would meet the requirements to be issued a DV cert anyways.
If the USG actually did seize control over gmail.com, and they had some CA sign a DV cert for them, how would that constitute a misissuance? The whole point of a DV certificate is that it only attests that the owner of the cert is the owner of the domain. The scenario we're talking about is a government becoming the new owners of a domain name.
But regardless of that, mitigating government overreach by means of having hundreds of sacrificial CAs is a pretty poor solution. What happens if Let's Encrypt gets blacklisted? That's a huge chunk of the internet gone right there until everyone gets around to replacing them. IANA doesn't have to have the root and TLDs delegated to a single entity. DNSSEC could be replaced by something requiring signatures from multiple different entities in multiple different jurisdictions to actually solve this problem. Have the root and global TLDs signed by at least 3 out of 5 entities with no more than 2 of those being from a Five Eyes nation. IANA already has a mediation process to resolve disputes with domain names, there's no reason why legitimate domain seizures couldn't be subjected to that process rather than just a unilateral court order to the registrar.
As for killing large existing CAs though, just look at how egregious Symantec was before Mozilla and Google ultimately decided to pull the plug. For years there'd be new ever more creative ways in which Symantec misissued certificates and their responses always seemed to be some variant of "Sorry, we didn't know we weren't supposed to issue certificates to entities other than the owner". There is still considerable friction to removing misbehaving CAs. As a matter of fact, Symantec in particular did misissue certificates for google.com back in 2015 during that whole test certificate debacle.
You mean DANE? Chrome had that for a short while but then removed it.
Sorry I'm confused; you need dnssec for Dane of course...
Like a blockchain-based DNS provider?
I built a simple DNS (and HTTP headers, and SSL) tool that some may like - https://DNSApe.com - and DNSSEC lookups are coming soon!
This is the kind of analysis that makes sense if you read RFCs at face value, or columns from network engineers at CircleID. It does not reflect the real world.
Here's a breakdown of the real world implications of these three protocols. They are in fact simpler than this analysis suggests.
DoT and DoH are related efforts. DNSSEC is unrelated to DoT or DOH.
DNSSEC is a ~25-year-old effort to sign DNS records, so that attackers who control caches can't spoof records. In 25 years, through 3 revisions of the protocol, 2 of them major, DNSSEC has seen practically no deployment outside of Europe, where registrars enable it automatically (and thus control the associated keys). In particular: with the exception of Cloud Flare, which provides DNSSEC services, and some Paypal domains, no major tech companies sign their zones with DNSSEC.
For a bunch of reasons, DNSSEC is probably a dead letter (I'm not calling time of death yet, but I expect to within in the next 6 months). In particular: protocol-level defenses against record spoofing just aren't very relevant. Much of the Internet runs on TLS (if you don't, DNSSEC is the least of your problems). The WebPKI (TLS CA system) has in-progress mitigations against spoofing, and more in the pipeline, and all of them put together will cost a tiny fraction of what DNSSEC will cost. For a year or two, SMTP TLS was the great hope of DNSSEC deployment, the last major mainstream application that had a security gap addressable directly with DNSSEC. But then the major mail providers all (all) got together and came up with SMTP-STS to address that gap directly.
It is hard to think of a real threat that end-user adoption of DNSSEC would address. I like to joke that the DNSSEC root keys could end up on Pastebin today and network engineers around the world could sleep the resulting Jira tickets for a week or two before deciding whether to just backlog them. Except I'm not really joking about that at all.
Which brings us to DoT and DoH.
The problem you do actually have with DNS today, especially if you're in the US, is that your large ISP is abusing DNS to monetize your traffic. I'm on AT&T, and, with their standard DNS, if I type a nonexistent domain into my browser, I'm on an AT&T landing page. ISPs are actively attacking DNS today for all their customers.
DoT and DoH tunnel DNS out of untrusted networks to a resolver on a hopefully more-trusted network (that is: there isn't that much point to DoT'ing or DoH'ing to your ISP's nameservers; you care about DoH/DoT if you want to use a third-party resolver, which you should).
Both DoT and DoH use TLS to secure DNS lookups. Protocol nerds will have fascinating discussions about the tradeoffs between the two approaches, but from a practical perspective, for home users, here's the real difference: DoT has a kill-switch for network operators, and DoH doesn't. A network operator that doesn't want you DoT'ing can stop you, because DoT deliberately runs on an oddball port. DoH, on the other hand, very deliberately runs on 443/tcp, so that it costs more to filter.
Do you want a kill switch in your DNS privacy tunnel? That depends on who you are. If you're an enterprise network operator, you want the kill switch, so you can (reasonably!) force your endpoints to funnel their DNS lookups through recursors you control and monitor. If you're a home user, you very much do not want the kill switch; if you decide you want to use Google DNS rather than your In-Flight Wi-Fi provider's DNS, it should not be up to your airline or their wifi provider whether you do that.
> with the exception of Cloud Flare, which provides DNSSEC services, and some Paypal domains, no major tech companies sign their zones with DNSSEC.
I was curious and tested the domains of the Fortune 500 as compiled at https://blog.dofo.com/fortune-500-domain-names/. Here's the list I came up with:
I'm not agreeing or disagreeing with your statements or sentiments; I just didn't want my efforts to go to waste.No, this is super helpful.
Booz Allen, United Technologies, and Raytheon are government contractors. For several years, the USG had a policy of requiring DNSSEC for its own internal zones and had sent signals that its partners would require DNSSEC as well. But a year and a half ago, the USG rescinded the requirement, and no longer recommends DNSSEC even for internal .gov zones.
Comcast is an interesting example because their adoption of DNSSEC broke a major project rollout: the week HBO NOW became available, it was unreachable from their networks due to a DNSSEC misconfiguration.
Another data point: of the Alexa Top 50 in the US, only FORCE.COM is DNSSEC-signed. But SALESFORCE.COM isn't; similarly, Paypal is signed, but its popular subsidiaries like Braintree and Venmo aren't. Or take the Moz 500; you'll find Mozilla is signed, as are a bunch of .GOV sites (see above), some European sites, and, if we're keeping score in the US, also Fox News, Time, Mediafire, and, weirdly, Themeforest. For reasons I do not understand, Stanford, Berkeley, and CMU have taken the time to sign as well. And that's it.
(For others reading: you can take a list of domains and do a quick spot check for DNS by just running "host -t ds (domain)".)
Where is there a rescindment of usg public dnssec requirements? It's still a requirement even for fedramp-low.
https://www.fedramp.gov/search-results/?search=dnssec
https://cloud.gov/docs/compliance/domain-standards/#dnssec
Note that cloud.gov is FedRAMP-authorized and does not itself support DNSSEC, which I point out in addition to the rationale cloud.gov provides on that link (which answers your direct question).
The root issue (pun not intended) is that DNS is not fully encrypted, not even point-to-point, DNSSEC only provides an integrity check, no encryption; DoT/DoH is only used between a resolver and a client as a last-mile solution. No robust security can be derived from the absence of full encryption - there is none, ultimately the traffic is sent in clear over the Internet backbone. You must make your own choice of trust for sending traffic in cleartext - your local network at home/school/hotel, your rented VPS provider, your ISP, or Google/CloudFlare.
Given that CloudFlare already has 13%+ market share, as an end-user, if my primary threat is eavesdropping in the middle, not eavesdropping by CloudFlare (or by NSA's subpoena or NSL), it's actually reasonable to trust the tech giants. Using CloudFlare's DoH server helps me to end-to-end encrypt my query of 13% of the domain names! Also, CloudFlare has business plan to adopt private encrypted DNS links to other authoritative servers, and they already have a private channel with Facebook, it's even better! Don't start sending hate replies, I know the bigger picture is that it allows CloudFlare to effectively monopolize DNS is extremely harmful in the long run, and I'm worried. But I simply don't see a perfect alternative solution that allows one to self-host a resolver at home with end-to-end encryption to communicate with authoritative servers.
You see, the end results that everyone should work towards is introducing encryption to the missing resolver-authoritative server link.
DNSCurve was developed in 2005 as a practical and high-performance protocol for deployment on authoritative servers, and fill the missing link, the protocol is great, DNSCrypt was its direct descendant for last-mile client-resolver encryption.
It was ultimately not adopted, partially because of many hate DJB's personal style of taking an aggressive position over technical issue, especially his attack on DNSSEC. But also, the final reason was that the ICANN has stated that, in the case of the DNS Root zone servers, DNSCurve will never ever be implemented. First because its threat model doesn't include the authoritative servers themselves, and it gives them the private key. This is fine for private use, but the DNS root servers are controlled by many political entities, and ICANN doesn't believe trusting them is acceptable. DNSSEC was designed in a way to avoid giving the ultimate key to root servers, but not DNSCurve. Also, DJB hated DNSSEC so much that DNSSEC cannot be used to sign the pubkey for DNSCurve resolver - oops!
In the future, we should work toward a solution for resolver-authoritative server encryption. In the article, the author mentioned DNS-over-TLS is a potential solution, if so, we should push to deploy DNS-over-TLS on major authoritative servers, or perhaps one day, on the root servers if a solution has been worked out.
Only then, it could allow us to say farewell to CloudFlare's DNS and Google's DoH resolvers.
* https://en.wikipedia.org/wiki/DNSCurve
http://stats.dnssec-tools.org/#