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.
> 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 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.
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)?