Was wondering how long it'd take you to come in and trash talk DNSSEC. And now with added FUD ("and once you press that button it's much less likely that you're going to leave your provider").
At least you're consistent.
At least you're consistent.
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.
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.
"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)
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.
This seems really odd, probably fundamentally incorrect. "Believing something over time means it is less likely that you are engaging in good faith"? Totally insane take.
No it isn't? If I guess what time it is and then look and see that it's around sunset, which is evidence towards my initial guess being right, it is not "suspicious". This is just a fundamentally broken model of evidence.
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.
So if the router between the web server and the Internet is compromised, it can just get trusted certs for all the HTTPS traffic going through it, enabling transparent MITM to inject its payload.
So even if you fully control the network path, you will somehow have to get access to my private key material.
Unless you had a CAA record saying only LE certs from your account are valid. And maybe you want that record to be authenticated.
DNSSEC is great for super tiny sites. I only run a single server, but it's strongly recommended that every domain has at least two independent nameservers, ideally with anycasted IPs. DNSSEC lets me fully self-host my DNS, while also letting me add secondary mirrors to get the additional independent nameservers.
Of course, you can add secondary mirrors without DNSSEC (and this is still quite common), but DNSSEC means that I don't have to trust these mirrors [0], since DNSSEC means that they can't forge invalid responses without my private key. I'd almost argue that if you're using secondary mirrors without DNSSEC enabled, then you're not "really" self-hosting, since you're completely reliant on the third-party mirrors being trustworthy.
For larger sites that can afford multiple independent nameservers or for anyone who wants to use a hosted DNS service, then DNSSEC probably offers fewer benefits, since in those cases you're presumably able to trust all your nameservers.
[0]: Well, I still need to trust them a little bit for non-DNSSEC-supporting clients, but most of the major resolvers support DNSSEC these days. And even then, this makes an attack much more detectable than it would be otherwise.
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.
Among others:
Let’s Encrypt was created through the merging of two simultaneous
efforts to build a fully automated certificate authority. In 2012, a
group led by Alex Halderman at the University of Michigan and
Peter Eckersley at EFF was developing a protocol for automatically
issuing and renewing certificates. Simultaneously, a team at Mozilla
led by Josh Aas and Eric Rescorla was working on creating a free
and automated certificate authority. The groups learned of each
other’s efforts and joined forces in May 2013.
...
Initially, ISRG was funded almost entirely through large dona-
tions from technology companies. In late 2014, it secured financial
commitments from Akamai, Cisco, EFF, and Mozilla, allowing the
organization to purchase equipment, secure hosting contracts, and
pay initial staff. Today, ISRG has more diverse funding sources; in
2018 it received 83% of its funding from corporate sponsors, 14%
from grants and major gifts, and 3% from individual giving.
> and it's still run on donations (even if they come from private actors).
I agree, but I think it's important to be precise about what's happening here, and like I said, it's never been the case that LE was really funded by non-profits.
> > 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.
I think this is a category error. The main operational cost for DNSSEC is not really the root, which is comparatively low load, but rather the distributed operations for every registry/registrar, and server to register keys, sign domains, etc.
One way to think about this is that running a TLD with DNSSEC is conceptually similar to operating a CA in that you have to take in everyone's keys and sign them. It's true you don't need to validate their domains, but that's not the expensive part. Operating this machinery isn't free, especially when you have to handle exceptional cases like people who screw up their domains and need manual help to recover. Now, it's possible that it's a marginal incremental cost, but I doubt it's zero. Upthread, you suggested that people are already paying for this in their domain registrations, but that just means that the TLD operator is going to have to absorb the incremental cost.
However, I'm don't feel sorry for registrars or TLDs. Verisign selling HTTPS certs while running the root TLDs is a conflict of interest and I believe the perverse incentives are a big part of the reason why DNSSEC and DANE are stalled out. TLDs are a monopoly business and ICANN is quasi-commercial entity that should never have been a for-profit business.
I certainly think it is fair to ask them to pay for all this.
I actually agree with you that in an abstract architectural sense a DNSSEC-style solution for authenticating they keys for endpoints is better. The problem from my perspective is that for a number of reasons that we've explored elsewhere in this thread, there is no practical way to get there from here.
To put this more sharply: in the world as it presently is with ubiquitous WebPKI deployment, the marginal benefit of DNSSEC strikes me as quite modest, even if it were universally deployed. Worse yet, the incremental benefit to any specific actor of deploying DNSSEC is even lower, which makes it very hard to get to universal deployment.
> However, I'm don't feel sorry for registrars or TLDs. Verisign selling HTTPS certs while running the root TLDs is a conflict of interest and I believe the perverse incentives are a big part of the reason why DNSSEC and DANE are stalled out. TLDs are a monopoly business and ICANN is quasi-commercial entity that should never have been a for-profit business. > >I certainly think it is fair to ask them to pay for all this.
I also do not feel sorry for registrars. However, it's also not clear to me that if somehow they were forced to incur incremental cost X per domain name, they would not find a way to pass it onto us. With that said, I also don't think that's really why DNSSEC and DANE are stalled out; rather I think that it's the deployment incentives I mentioned above.
Note that despite the confusing naming and the fact that VeriSign was once a CA, they no longer are and have not been since 2010, as described in the second paragraph of their Wikipedia page. https://en.wikipedia.org/wiki/Verisign. In fact, in my experience VeriSign is very pro-DNSSEC.
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.
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.
DNSSEC lets you delegate a subtree in the namespace to a given public key. You can hardcode your DNSSEC signing key for clients too.
Don't get me started on how badly VPN PKI is handled....
The WebPKI and DNSSEC run global PKIs because they routinely introduce untrusting strangers to each other. That's precisely not the SSH problem. Anything you do to bring up a new physical (or virtual) involves installing trust anchors on it; if you're in that position already, it actually harms security to have it trust a global public PKI.
The arguments for things like SSHFP and SSH-via-DNSSEC are really telling. It's like arguing that code signing certificates should be in the DNS PKI.
Providing global PKI and enabling end-to-end authentication by default for all clients and protocols certainly would make the internet a safer place.
Do you hardcode Github and AWS keys in your SSH config? Do you think it would be beneficial to global security if that happened automatically?
Further, I haven't "moved on to another argument". Can you answer the question I just asked? If I have an existing internal PKI for my fleet, what security value is a trust relationship with DNSSEC adding? Please try to be specific, because I'm having trouble coming up with any value at all.
It's a solved problem, basically.
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.
If the IP is anycast, all the better.