
DNS Security: Threat Modeling DNSSEC, DoT, and DoH - fanf2
https://www.netmeister.org/blog/doh-dot-dnssec.html
======
kodablah
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)?

~~~
tptacek
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.

~~~
kodablah
> 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.

~~~
zamadatix
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.

~~~
kodablah
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.

~~~
zamadatix
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.

------
motohagiography
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](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.

------
hansiess
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](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)?

------
cryptonector
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.

~~~
tptacek
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.

~~~
cryptonector
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.

~~~
tptacek
I addressed that in my comment: it's never been easier to get caught, since
certificate issuance is now cryptographically logged.

------
CiPHPerCoder
> 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?

~~~
cuillevel3
This comes to mind: [https://sockpuppet.org/blog/2015/01/15/against-
dnssec/](https://sockpuppet.org/blog/2015/01/15/against-dnssec/)

~~~
CiPHPerCoder
Very yes. `tptacek has great takes on DNSSEC

~~~
wtallis
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.

~~~
tptacek
Feel free to provide an example!

~~~
MertsA
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.

~~~
tptacek
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.

~~~
MertsA
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.

------
codercotton
I built a simple DNS (and HTTP headers, and SSL) tool that some may like -
[https://DNSApe.com](https://DNSApe.com) \- and DNSSEC lookups are coming
soon!

------
tptacek
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.

~~~
wahern
> 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/](https://blog.dofo.com/fortune-500-domain-names/). Here's the list I
came up with:

    
    
      aetna.com
      boozallen.com
      centene.com
      cmsenergy.com
      comcastcorporation.com
      key.com
      magellanhealth.com
      paypal.com
      raymondjames.com
      raytheon.com
      simon.com
      theice.com
      thorindustries.com
      usaa.com
      utc.com
      xerox.com
    

I'm not agreeing or disagreeing with your statements or sentiments; I just
didn't want my efforts to go to waste.

~~~
tptacek
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)".)

~~~
Abekkus
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://www.fedramp.gov/search-results/?search=dnssec)

~~~
tptacek
[https://cloud.gov/docs/compliance/domain-
standards/#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).

------
segfaultbuserr
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](https://en.wikipedia.org/wiki/DNSCurve)

------
cryptonector
[http://stats.dnssec-tools.org/#](http://stats.dnssec-tools.org/#)

