[cpach]

DNSSEC has aged very poorly. I also believe it operates at the wrong layer. When you surf to chase.com you want to make be sure that the website you see is actually JPMorganChase and not Mallory’s fake bank site. That’s why we have HTTPS and the WebPKI. If your local DNS server is poisoned somehow that’s obviosly not good, but it cannot easily send you to a fake version of chase.com.

Part of why it’s so hard for Mallory to create a fake version of a bank site is Certificate Transparency. It makes it much much harder to issue a forged certificate that a browser such as Chrome, Safari or Firefox will accept.

For further info about the flaws of DNSSEC I can recommend this article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ It’s from 2015 but I don’t think anything has really changed since that.

[perching_aix]

There are a lot of things that are different for sure since that article's release, for example the crypto, but also the existence of DoH/DoT and that it is leaps and bounds more deployed. They also talk about key pinning, but key pinning has been dead for a while and replaced by exactly CT.

I'm also not sure how much to trust the author. The writing is very odd language wise and they seem to have quite the axe to grind even with just public CA-based PKI, let alone their combination. The FAQ they link to also makes no sense to me:

> Under DNSSEC/DANE, CA certificates still get validated. How could a SIGINT agency forge a TLS certificate solely using DNSSEC? By corrupting one of the hundreds of CAs trusted by browsers.

It's literally what I'd want TLSA enforcement for to combat.

[tptacek]

The existence of DoH hurts DNSSEC, it doesn't help it. While privacy is the motivating use case for DoH, it's also the case that on-path attackers can't corrupt the results of a DoH query; they have to move upstream of it.

The dream of TLSA as a bulwark against suborned CAs has always been problematic, because the security of TLSA records collapses down to that of the TLD operators, the most popular of which are state actors or proxies for them, and most of the remainder are essentially e-commerce firms, not trust anchors.

But that doesn't matter, because TLSA as an alternative to the WebPKI is already dead on arrival. So many people have problematic access to DNS that no browser can ship hard-fail DANE; in the (extraordinarily unlikely) future world where mainstream browsers do DANE, everybody will have soft-fail DANE falling back to the WebPKI. So, instead of a small number of (state-run!) PKI roots, you'll have the thousands of legacy operators plus the state-run PKI roots.

This problem motivated the design of "stapling" protocols, where we'd basically throw away the DNS part of the protocol, and just keep the TLSA records, and attach them to the TLS handshake. For several years, this was the last best hope for DANE adoption (read Geoff Huston on this, he's a DANE supporter and he's great), and it all fell apart because nobody could get the security model right.

It's at this point I like to remind people that the browsers basically had to shake down the CAs to get Certificate Transparency to happen. They held almost all the cards (except for antitrust claims, which were wielded against them) --- "comply with CT, or we'll remove you from our root program". But browsers can't do that with DNS TLD operators; they hold none of the cards. So, in addition to the fact that there's no "DNS Transparency" on the horizon, there's also none of the leverage required to actually get it deployed.

DANE does not work. DNSSEC is a dead letter. It's long past time for people to move on. I have a lot of hope for what we can accomplish with ubiquitous DoH-like lookups.