It's a common misconception that DNSSEC is not needed if you have TLS. Two reasons come to mind:
1) CAs will happy issue TLS certificates if you can spoof DNS. In the past you would have to spoof MX records, with letsencrypt (or other CAs that implement ACME) you have to spoof the A/AAAA of the domain you want to attack (and deny the existance of CAA). Surprisingly it is almost never mentioned that the security of TLS is completely dependent on an extremely insecure protocol like DNS.
2) The only thing that comes close to practical email security is DANE. With DANE you can tell the sending mail server that TLS is available (to prevent downgrade attacks) and what the certificate or key is. Even if you don't use email for communication, many systems include email verification as part of a password reset procedure.
> it is almost never mentioned that the security of TLS is completely dependent on an extremely insecure protocol like DNS
Yes, the most likely reason for that being that... it isn't true? The CA ecosystem is fairly resilient against DNS and even BGP hijacks, and simply ignoring innovations like CT is... not persuasive.
> With DANE you can tell the sending mail server that TLS is available
Yeah, or you just refuse to send and receive any email without STARTTLS being in effect. You won't miss much.
CT is a passive tool that doesn't really help to prevent incidents.
In the 2017 Brazilian bank hack [1] Let's Encrypt denied any wrongdoing and clearly stated that DV means nothing more than DV (that is reasonable). These certificates were logged in CT but it was only discovered afterwards.
CT alters the economics of large-scale misissuance, actively, by creating consequences for it. CAs have been distrusted for issues detected by CT. That's not "passive".
You’re right. I would suggest that the commenter is right in spirit but the framing and the word “passive” aren’t compatible.
CT is passive in that it provides an ability to be reactive, but it isn’t a proactive technology. It can’t “actively” do anything other than tell you something has happened.
With password resets your own mail server is not involved. STARTTLS or not. In the absence of DANE, mail servers will not require or validate certificates. So the reset link will get to the attacker in the vast majority of cases.
Yeah, password reset emails are sure a huge vulnerability. Nothing to do with DANE, though, since that won't solve that issue either (not going to spell out all the reasons for that, but suffice to say that once a zone's registrar account is compromised, as with all examples so far here, the 'turn off DNSSEC' option is even deadlier than all other extremely practical attacks otherwise possible against the protocol...)
It's simply one more step in an attack chain. Again, all of the examples mentioned upthread involve compromising the zone's registrar accounts (through old-fashioned 'spear-phishing', which works regardless of DNSSEC, DANE, 2FA, or whatever -- otherwise, we wouldn't be reading about it!).
The argument "well, they were able to compromise BGP, but DANE surely would have stopped them" is not only unsupported, but not particularly likely either.
I can't find it either, but that's just because I don't read Korean and can't deep-dive into the actual attack details, hidden behind the summary you posted.
But let me pose a counterfactual: I am the owner of example.nl, and I publish the memoirs of one YA, which the .nl government desperately wants to suppress, for, eh, reasons. The .nl zone requires DNSSEC by default, but I cleverly host my zone on CloudFlare and disable DNSSEC. I also use LetsEncrypt to secure my site, which is only available via HTTPS.
In response, the .nl government instructs all ISPs in the entire EU to route all CloudFlare traffic to its middlebox, and it obtains an SSL certificate in example.nl's name from Diginotar, a notably reputable SSL vendor. It uses all that power to host an alternative version of YA's memoirs.
Which percentage of Internet users will actually see that alternative version? And how many millions of Euros will I be able to collect from the lawsuits afterwards? Bonus question: how much will it cost to replace the melted-down middlebox?
As the article points out, the overwhelming majority of the largest sites on the Internet, with the best-resourced security teams in the world, disagree with this assessment and do not sign their zones.
DNSSEC is a complicated kitchen sink that doesn't do the fundamentals (encrypt DNS traffic). It is also very black-box with the current tooling (not by design, but by implementation) which makes deployment perilous and confusing.
It's really a PKI infrastructure masquerading as a secure DNS system.
There's value in a PKI infrastructure for domain names, but it probably won't look exactly like DNSSEC. And there's value in encrypting DNS, but that is definitely not DNSSEC. I helped invent and deploy DNSCrypt which is strong encrypted DNS, but doesn't provide the PKI components. There are plenty of ways to do that part, however, that would be much lighter in weight than DNSSEC.
I'm not motivated to do it now with my current day job (American Dynamism) but someone out there could.
How can we measure DNSSEC adoption? We could take the Tranco top 1M domain names and poll them to see how many are DNSSEC-signed. A recent scan of this domain name list shows that 94,317 of these names are validly signed with DNSSEC, or 9.4%. The issue with this form of average statistic is that it equally weights all of these million domain names, whereas a more relevant statistic would be to weight each domain name by its relative “use” in some fashion. Perhaps there is a different approach that takes this relative use weighting between domain names into consideration.
It's so much worse than this, and I think he must know that. The Tranco list (which is very cool: it's like the Moz500 or other popularity-contest lists like that, but research-oriented, academic, and ostensibly rigorous) is ranked. The first domain on the list is Google, and so on.
He used the Top 1M for a reason. If he wanted to take the top 1000, he could just `head -1000` the list. But the impact on his 9.4% figure would be stark.
Prevent ISP from intercepting DNS queries? ISP cannot see the contents of the DNSCrypt encrypted DNS queries.
But person operating DNSCrypt cache where the queries are sent _can_ see the contents of the DNS queries.
DNSCrypt receives encrypted queries but then it sends these queries _unencrypted_ across the internet.
Morever the DNSCrypt cache receives _unencrypted_ DNS responses.
Anyone eavesdropping on the network can read and tamper with the contents of these packets, and impersonate packet senders.
What if ISP sets up a DNSCrypt cache somewhere on the internet? How would a DNSCrypt user know?
What makes it safe to share the contents of DNS queries with operator of DNSCrypt cache but not operator of ISP DNS cache?
What if the computer could send encrypted DNS queries to the authoritative nameserver for a domain name _directly_ instead of sending the queries to a DNSCrypt cache operator? What if the computer user could avoid using a third party intermediary: a DNSCrypt cache operator, an ISP, etc.?
As it happens someone designed a method for doing so, including the underlying cryptography.
That method expects that computer users run their _own_ caches instead of using one operated by third parties, such as an ISPs, DNSCrypt cache operators, OpenDNS, Cloudflare, Google DNS, Quad9, etc.
The creators of DNSCrypt copied that person's work to "invent" DNSCrypt.
Instead of using a local DNS cache bound to the computer owner's loopback that sends and recieves encrypted DNS packets directly to authoritative nameservers, they chose to require computer users to send DNS queries to _third party_ DNSCrypt cache operators as above.
If all packets carrying DNS data on the internet are to be encrypted it will require cooperation from authoritative nameservers.
I have run experiments on home network where I serve an entire zone from an authoritative nameserver fronted by a DNSCurve forwarder.
Others are running authoritative nameservers fronted by DNSCurve forwarder on the internet. AFAIK none of them have had any problems.
There is also a third party DNS service that runs DNSCurve forwarders in front of its nameservers.
Imagine a non-ICANN DNS registry that uses DNSCurve forwarders and only allows encrypted DNS.
21 comments
[ 2.9 ms ] story [ 62.5 ms ] threadYes, the most likely reason for that being that... it isn't true? The CA ecosystem is fairly resilient against DNS and even BGP hijacks, and simply ignoring innovations like CT is... not persuasive.
> With DANE you can tell the sending mail server that TLS is available
Yeah, or you just refuse to send and receive any email without STARTTLS being in effect. You won't miss much.
In the 2017 Brazilian bank hack [1] Let's Encrypt denied any wrongdoing and clearly stated that DV means nothing more than DV (that is reasonable). These certificates were logged in CT but it was only discovered afterwards.
[1] https://www.wired.com/2017/04/hackers-hijacked-banks-entire-...
I don't think DNSSEC would have helped there either. That's an interesting case study, thanks for posting it.
CT is passive in that it provides an ability to be reactive, but it isn’t a proactive technology. It can’t “actively” do anything other than tell you something has happened.
With password resets your own mail server is not involved. STARTTLS or not. In the absence of DANE, mail servers will not require or validate certificates. So the reset link will get to the attacker in the vast majority of cases.
ACME validation with dns-01 relies only on DNS. Routing does not matter other than to create DoS.
The argument "well, they were able to compromise BGP, but DANE surely would have stopped them" is not only unsupported, but not particularly likely either.
I can't find it.
But let me pose a counterfactual: I am the owner of example.nl, and I publish the memoirs of one YA, which the .nl government desperately wants to suppress, for, eh, reasons. The .nl zone requires DNSSEC by default, but I cleverly host my zone on CloudFlare and disable DNSSEC. I also use LetsEncrypt to secure my site, which is only available via HTTPS.
In response, the .nl government instructs all ISPs in the entire EU to route all CloudFlare traffic to its middlebox, and it obtains an SSL certificate in example.nl's name from Diginotar, a notably reputable SSL vendor. It uses all that power to host an alternative version of YA's memoirs.
Which percentage of Internet users will actually see that alternative version? And how many millions of Euros will I be able to collect from the lawsuits afterwards? Bonus question: how much will it cost to replace the melted-down middlebox?
It's really a PKI infrastructure masquerading as a secure DNS system.
There's value in a PKI infrastructure for domain names, but it probably won't look exactly like DNSSEC. And there's value in encrypting DNS, but that is definitely not DNSSEC. I helped invent and deploy DNSCrypt which is strong encrypted DNS, but doesn't provide the PKI components. There are plenty of ways to do that part, however, that would be much lighter in weight than DNSSEC.
I'm not motivated to do it now with my current day job (American Dynamism) but someone out there could.
It's so much worse than this, and I think he must know that. The Tranco list (which is very cool: it's like the Moz500 or other popularity-contest lists like that, but research-oriented, academic, and ostensibly rigorous) is ranked. The first domain on the list is Google, and so on.
He used the Top 1M for a reason. If he wanted to take the top 1000, he could just `head -1000` the list. But the impact on his 9.4% figure would be stark.
Prevent ISP from intercepting DNS queries? ISP cannot see the contents of the DNSCrypt encrypted DNS queries.
But person operating DNSCrypt cache where the queries are sent _can_ see the contents of the DNS queries.
DNSCrypt receives encrypted queries but then it sends these queries _unencrypted_ across the internet.
Morever the DNSCrypt cache receives _unencrypted_ DNS responses.
Anyone eavesdropping on the network can read and tamper with the contents of these packets, and impersonate packet senders.
What if ISP sets up a DNSCrypt cache somewhere on the internet? How would a DNSCrypt user know?
What makes it safe to share the contents of DNS queries with operator of DNSCrypt cache but not operator of ISP DNS cache?
What if the computer could send encrypted DNS queries to the authoritative nameserver for a domain name _directly_ instead of sending the queries to a DNSCrypt cache operator? What if the computer user could avoid using a third party intermediary: a DNSCrypt cache operator, an ISP, etc.?
As it happens someone designed a method for doing so, including the underlying cryptography.
That method expects that computer users run their _own_ caches instead of using one operated by third parties, such as an ISPs, DNSCrypt cache operators, OpenDNS, Cloudflare, Google DNS, Quad9, etc.
The creators of DNSCrypt copied that person's work to "invent" DNSCrypt.
Instead of using a local DNS cache bound to the computer owner's loopback that sends and recieves encrypted DNS packets directly to authoritative nameservers, they chose to require computer users to send DNS queries to _third party_ DNSCrypt cache operators as above.
If all packets carrying DNS data on the internet are to be encrypted it will require cooperation from authoritative nameservers.
I have run experiments on home network where I serve an entire zone from an authoritative nameserver fronted by a DNSCurve forwarder.
Others are running authoritative nameservers fronted by DNSCurve forwarder on the internet. AFAIK none of them have had any problems.
There is also a third party DNS service that runs DNSCurve forwarders in front of its nameservers.
Imagine a non-ICANN DNS registry that uses DNSCurve forwarders and only allows encrypted DNS.