4 ms·

Calling Time on DNSSEC?

32 points by amaccuish 2y ago

edent 2y ago
Also worth noting how often DNSSEC causes outages. https://ianix.com/pub/dnssec-outages.html https://ianix.com/pub/dnssec-outages.html
- 1vuio0pswjnm7 2y ago
  Wish there as also a page like that for TLS (as used for "Web PKI").
phicoh 2y ago
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.
- PreInternet01 2y ago
  > 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.
  - alexey-salmin 2y ago
    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. [1] https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/ https://www.wired.com/2017/04/hackers-hijacked-banks-entire-...
    - mkj 2y ago
      "Kaspersky believes the attackers compromised the bank's account at Registro.br" I don't think DNSSEC would have helped there either. That's an interesting case study, thanks for posting it.
    - tptacek 2y ago
      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".
      - TheNewsIsHere 2y ago
        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.
  - phicoh 2y ago
    Here is a recent attack showing the lack of resilience in the CA ecosystem: https://freedom-to-tinker.com/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/ https://freedom-to-tinker.com/2022/03/09/attackers-exploit-f... 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.
- tptacek 2y ago
  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.
deleted 2y ago
[deleted]
davidu 2y ago
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.
tptacek 2y ago
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.
1vuio0pswjnm7 2y ago
What is purpose of DNSCrypt? 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.

32 points by amaccuish 2y ago

Also worth noting how often DNSSEC causes outages. https://ianix.com/pub/dnssec-outages.html https://ianix.com/pub/dnssec-outages.html

1vuio0pswjnm7 2y ago
Wish there as also a page like that for TLS (as used for "Web PKI").

phicoh 2y ago

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.

PreInternet01 2y ago
> 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.
- alexey-salmin 2y ago
  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. [1] https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/ https://www.wired.com/2017/04/hackers-hijacked-banks-entire-...
  - mkj 2y ago
    "Kaspersky believes the attackers compromised the bank's account at Registro.br" I don't think DNSSEC would have helped there either. That's an interesting case study, thanks for posting it.
  - tptacek 2y ago
    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".
    - TheNewsIsHere 2y ago
      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.
- phicoh 2y ago
  Here is a recent attack showing the lack of resilience in the CA ecosystem: https://freedom-to-tinker.com/2022/03/09/attackers-exploit-fundamental-flaw-in-the-webs-security-to-steal-2-million-in-cryptocurrency/ https://freedom-to-tinker.com/2022/03/09/attackers-exploit-f... 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.
tptacek 2y ago
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.

deleted 2y ago

[deleted]

davidu 2y ago

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.

tptacek 2y ago

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.

1vuio0pswjnm7 2y ago

What is purpose of DNSCrypt? 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.