Hacker News Reader

Comment by mjl- | Hacker News Reader

fwiw, i live in a country where rolling out dnssec apparently had some financial incentives for providers, which apparently helped adoption: https://stats.sidnlabs.nl/en/dnssec.html adoption still growing, more than 60% of .nl domains currently dnssec-signed, and around 60% of queries are from validation resolvers.

i looked up global stats. world map + tables about current validating resolver queries: https://stats.labs.apnic.net/dnssec. and this is the graph over time of for the world: https://stats.labs.apnic.net/dnssec/XA (30% validating, don't know what the additional 10% mixed means). i did a quick search, but didn't find global stats about domains being dnssec-signed.

dnssec is not easy/simple (especially when getting into the details), but i think the contemporary dns servers make it relatively easy to enable dnssec on a zone, managing the signing themselves.

i do like the idea of being able to set up secure connections without relying on CAs.

View on HN

Couple things here. First: the European provider DNSSEC adoption stuff is all based on the providers managing and custodying keys for their customers, which is security theater. We'd have universal DNSSEC adoption if nobody ever managed their own DNS! Second: the prospects of DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed. Third: even if a browser did enable DANE, so that some fraction of users could "rely" on it, they'd still be honoring the WebPKI, and you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure. Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT.

Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be.

I was going to say that the DANE PGPKEY stuff was another interesting use case for DANE, but on doing a search for clients who supported it, it seems the answer there has just been to use a .well-known https: url instead.

If even the PGP enthusiasts can't be bothered to use the approach, it must be well and truly dead.

> providers managing and custodying keys for their customers, which is security theater

isn't that similar to providers managing/having access to the tls keys? well, dns is a bit more essential. but plain dns isn't more secure. ideally we can all only access our own keys, but that doesn't seem to be the standard.

i have been wondering how common it is for dns operators to just serve (the signed) zones that get sent in by domain owners. and if that has technical hurdles for the operators (i'm sure the reason for many domain owners is they want to outsource responsibility).

> DNSSEC replacing CAs are slim-to-nil, since browser experiments with actually using DANE failed

seems like it for browsers. it seems dane for mail has a future. the alternative to dane, pki-based mta-sts, has downsides like tofu for policies and needing long-lived cachable policies, especially not great given the decentralized nature. currently, many domains have no protection for deliveries (unverified mx records & tls certs).

found this just now, interesting: https://ripe86.ripe.net/presentations/51-2023-05-23-dnssec.p... mentions tls with dane records inside. but not necessarily hopeful for dnssec, it is hard to change infrastructure. i always wonder to what extent new protocols are lobbied and their rollout preplanned vs hoping for the best.

> you'd be a trivial downgrade attack away from being put back into the WebPKI CA infrastructure.

i often wonder why not more "signals" about how to connect are in dns. perhaps lack of dnssec. with dnssec that becomes an option, preventing a downgrade. probably bad middleboxes that don't let certain dns requests through (a reason to encrypt). the trend seems to be https on a subdomain that serves a policy.

> Fourth, and finally, the roots of trust in DNSSEC are themselves commercial entities, and they're less trustworthy (if that's possible for you to imagine) than commercial CAs, because they're not required to participate in a public ledger like CT.

i should update my knowledge exactly on the good/bad about the dnssec trust roots. if there are good docs out there, i'm interested.

> Really, though, LetsEncrypt was the death knell for the DANE use case. Certificates are free now, and always will be.

true, it doesn't seem like we're in bad position with LE. and they keep getting better (shorter-lived certs). though perhaps we're getting a little bit reliant on this one CA.

> isn't that similar to providers managing/having access to the tls keys

Yes. Cloudflare-like solutions has access to all the TLS keys. In addition, any cloud solution with with anycast will have partners that has access to all keys, and there is no validation that all partners will respond with the exact same information. The only non-security theater is self hosting of everything with hardware and software under the user's full control.

> i have been wondering how common it is for DNS operators to just serve (the signed) zones that get sent in by domain owners.

Very common. As a service it is usually called slave zone or hidden master. Practically all DNS providers have this as a product. The solution for public key roll over varies between providers, and some TLDs have started to use CDS/CSYNC which removes the registrar from the whole chain. CDS/CSYNC is however a bit more rare so the more common method is to either use long lived keys or a registrar API for uploading new keys.

Whatever else you think about registrars and DNS providers managing DNSSEC, it simply is the case that none of this counts as "adoption". It's not "adoption" if domain owners aren't adopting it, and it's especially not adoption if the largest and most important domains fastidiously avoid it. You could get anything adopted Internetwide instantly if you just had ISPs quietly turn it on for everybody.

Does HTTPS adoption somehow not count if your web site provider adopts it, but not you? That is what you are essentially arguing. And just as most people do not run their own web server, even fewer people run their own DNS servers.

HTTPS adoption is universal. I don't have to pick apart the different modes and qualities of adoption. Most major websites won't even let you not use it anymore. The comparison is risible.

> I don't have to pick apart the different modes and qualities of adoption.

Actually, you do have to make proper counter-arguments. That is how a debate works. Simply declaring your opponent's arguments as "risible" is not cool.

If you please, explain how DNSSEC adoption is different from HTTPS adoption. They seem to have quite close analogs: In the usual case, both are done by the server operators (authoritative DNS server and web server, respectively), not by the end customers themselves, and the server operators also handle and hold all related public and private keys.

You seem to be arguing upthread that DNSSEC adoption somehow does not count since the end customer does not hold the keys themselves. But the same is the case for typical web hosting. So how is this different?

HTTPS is universally adopted. Meanwhile: the DNSSEC root keys could land on Pastebin tonight and nobody would need to be paged. The distinction is so clear that trying to pick apart the description seems disingenuous.

I don't think you're experiencing me being evasive so much as that I simply don't accept your premises.

> the DNSSEC root keys could land on Pastebin tonight and nobody would need to be paged.

I disagree with this ludicrous assertion, but you are answering a different question, so I will not pursue this question at this time, in favor of the issue at hand:

Upthread, you wrote that with “DNS providers managing DNSSEC”, “none of this counts as "adoption”. Why not? You also wrote that “providers managing and custodying keys for their customers […] is security theater”. How is this different from HTTPS keys? Why are HTTPS keys not “security theater”, but DNSSEC keys are?

I'm genuinely interested, because I've asked this question a bunch of times to a bunch of different audiences and never gotten an answer. So that thought experiment again: the DNSSEC root keys are fatally compromised. What are some specific entities that will require an immediate security response? Put differently: what specific entities depend today in any significant way on DNSSEC?

Remember when you're thinking about this that most (virtually all, really) of the largest and/or most important organizations on the Internet don't use DNSSEC, so it wouldn't make any difference at all to them. And, in case this needs saying, it doesn't really count (in the spirit of this thought experiment) if the entity you think of is, like, a DNSSEC provider; stipulate, DNSSEC providers themselves would freak out. But who else would?

I’ll note that you completely ignored the main topic and have jumped to another question. What guarantees do I have, if I engage with you on this new (and admittedly somewhat interesting) topic, that you won’t just again jump to something else mid-debate? You do not seem to be arguing in good faith.

I don't know that I've done that at all but do feel that I expressed this question directly, straightforwardly, and in easily falsifiable terms. It seems like it would be remarkable if you couldn't answer it, right?

Tell you what; I’ll answer your new question if you answer my original question which you evaded: Why are HTTPS keys not “security theater”, but DNSSEC keys are? (Details in my comment upthread.)

Because people generally do manage their own TLS keys. Everybody who has ever set up Certbot and LetsEncrypt has done so. You've misconstrued my argument about this, which says only that people who have domains autosigned by their registrars aren't a meaningful contributor to DNSSEC deployment, not that the huge share of DNSSEC deployment that those people represent is a sign that all DNSSEC key management is performative security theater. My argument is simpler and more limited than you've taken it for.

Now, to my question? Again: it seems like a very broad, very easily falsified argument. Who, other than DNSSEC providers themselves, would need to be paged if the DNSSEC root keys ended up on Pastebin? Be specific, if you can? Seems like this should be easy to answer!

> people generally do manage their own TLS keys.

What? No, most people do not run their own web server. Most people have their web site on a web host, and lets the web hoster manage it, including the TLS keys. Just like with DNS and the DNSSEC keys.

> Who, other than DNSSEC providers themselves, would need to be paged if the DNSSEC root keys ended up on Pastebin?

I freely admit that I don’t know. Beside ICANN, I’m guessing all the TLD operators, since their records can now be spoofed with impunity. But, I guess you could also ask: What would happen if, say, the keys for the X.509 certificates for google.com was leaked?

It would be a world-historic shitshow. The security teams at every F500 company would be woken up.

OK, but why? What could happen, in actual practice?

The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever.

> The fraction of validating queries is misleading because practically all validation happens in the recursive resolver, which doesn't provide security all the way to the client. At least as far as browser clients goes, we're as far away from setting up connections based on DNSSEC-validated keys as ever.

fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is.

i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled.

i used to dislike the unhelpful generic error messages for dnssec-related problems (servfail). perhaps that was holding adoption back. but extended dns errors (ede) seem to solve that, though i don't know how commonly the detailed errors make it up the stack in old software.

> fair point, perhaps partially compensated through tls-protection for recursive dns. don't know how common that is.

Yes, but this isn't a replacement for the WebPKI because it would allow the recursive to impersonate any site, which is obviously unacceptable.

> i wonder whether there is any move by e.g. linux distro's towards including a dnssec-verifying resolver by default. whether they think it's not worth the trouble, or what the inflection point will be. i usually install unbound on new machines. i believe openbsd comes with unbound by default? assuming that's with dnssec-validation enabled.

A year or so ago we took some measurements of DNSSEC success rates with Firefox on known-good domains that we controlled and the results were very bad. I don't have the data to hand right at the moment, but requiring DNSSEC validation would have produced unacceptably high failure rates.

Reply on news.ycombinator.com