I don't think I'm out on a limb suggesting that random small domains should not enable DNSSEC. There's basically zero upside to it for them. I think there's basically never a good argument to enable it, but at least large, heavily targeted sites have a colorable argument.
I've struggled to think of an especially unexamined example because after all they tend to sit out of conscious recall, I think the best I can do is probably that my favourite comic book character is Miracleman's daughter, Winter Moran. That's a consistent belief I've held for decades, I haven't spent a great deal of time thinking about it, but it's not entirely satisfactory and probably there is some introduced nuance, particularly when I re-examined the contrast between what Winter says about the humans to her father and what her step-sister Mist later says about them to her (human) mother because I was writing an essay during lockdown.
"More secure" begs the question "against what?", which the blog post doesn't seem to want to go into. Maybe it's secure from hidden tigers.
My favourite DNSSEC "lolwut" is about how people argue that it's something "NIST recommends", whilst at the same time the most recent major DNSSEC outage was......... time.nist.gov! (https://ianix.com/pub/dnssec-outages.html)
Please don't stealth-edit your posts after I respond to them. If you need to edit, just leave a little note in your comment that you edited it.
Yes it did hit HN and you just said, "I stand by what I wrote." and then complain about buggy implementations and downtime connected to DNSSEC. As if that isn't true for all technologies, let alone /insecure/ DNS. DNS is connected to a lot of downtime because it undergirds the whole internet. Making the distributed database that delegates domain authority cryptographically secure makes everything above it more secure too.
I rebutted your arguments point-by-point. You don't update your blog post to reflect those arguments nor recent developments, like larger key sizes.
I write things people disagree with all the time. I can't recall ever having been mad that people didn't cite me for things we disagree about. Should I have expected all the people who hated coding agents to update their articles when I wrote "My AI Skeptic Friends Are All Nuts"? I didn't realize I was supposed to be complaining about that.
I'm frustrated that you seem to blow me off and insult me when I try to engage in good faith discussion, but I'm not angry at you. I just ran into this post while procrastinating at work and here we are, in the same loop.
I think we are both trying to make the internet a safer place. It's sad we can't seem to have a productive conversation on the matter.
Why? I can see this argument for large domains that might be using things like anycast and/or geography-specific replies. But for smaller domains?
> There's basically zero upside to it for them.
It can reduce susceptibility to automated wormable attacks. Or to BGP-mediated attacks.
But there is no money in making that a solution and a TON of money in selling you BS HTTPS certs. There is a lot of people spreading FUD about it. It's a shame.
Ah yes, because lets encrypt is rolling in the $$$$.
The sad thing is that Mozilla and others have to spend millions bankrolling Let's Encrypt instead of using the free, high assurance PKI that is native to the internet!
It's of course possible that the total numbers are lower than the costs of the WebPKI -- I haven't run them -- but I don't think free is the right word.
LE isn't primarily funded by non-profits, as you can see from the sponsor list here: https://isrg.org/sponsors/
Anyway, I think there's a reasonable case that it would be better to have the costs distributed the way DNSSEC does, but my point is just that it's not free. Rather, you're moving the costs around. Like I said, it may be cheaper in aggregate, but I think you'd need to make that case.
I mean, Mozilla got the ball rolling and it's still run on donations (even if they come from private actors).
> Like I said, it may be cheaper in aggregate, but I think you'd need to make that case.
The PKI is already there: we have 7 people who can do a multisig for new root keys. There is a signing ceremony in a secure bunker somewhere that gets live streamed. The HSMs and servers are already paid for. Cert transparency/monitoring is nice but now it's hard-coded to HTTPS instead of being done more generically. There's a lot of duplicated effort.
Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.
It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.
With DNSSEC, a host with control over a domain's DNS records could use that to issue verifiable public keys without having to contact a third party.
I ran into this while working on decentralized web technologies and building a parallel to WebPKI just wasn't feasible. Whereas we could totally feed clients DNSSEC validated certs, but it wasn't supported.
1. Things that use TLS and hence the WebPKI 2. Other things.
None of what you've written here applies to the TLS and WebPKI case, so I'm going to take it that you're not arguing that DNSSEC validation by clients provides a security improvement in that case.
That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
It would benefit the likes of Wikileaks. You could do all the crypto in your basement with an HSM without involving anyone else.
> That leaves us with the non-WebPKI cases like SSH. I think you've got a somewhat stronger case there, but not much of one, because those cases can also basically go back to the WebPKI, either directly, by using WebPKI-based certificates, or indirectly, by hosting fingerprints on a Web server.
But do they? That requires adding support for another protocol.
I would like to live in a world where I don't have to copy/paste SSH keys from an AWS console just to have the piece-of-mind that my SSH connection hasn't been hijacked.
There may be other applications where a global public PKI makes sense; presumably those applications will be characterized by the need to make frequent introductions between unrelated parties, which is distinctly not an attribute of the SSH problem.