That doesn't make it correct. Imagine if someone had said, "We don't need to secure HTTP, we'll just rely on E2E encryption and trust-on-first-use". I would really like it if we had a way to automatically cryptographically verify non-web protocols when they connect.
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.
Mark Shuttleworth paid for his ride to the space station by selling HTTPS certs.
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 not really free, though. Rather, the costs are distributed rather than centralized, but running DNSSEC and keeping it working incurs new operational costs for the domain holders, who need to manage keys and DNSSEC signing, etc. And of course there are additional marginal costs to the registrars of managing customer DNSSEC, both building automation and providing customer service when it fails.
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.
I mean, I guess the costs are paid for by the domain name fee. But at least it doesn't have to be a charitable activity covered by non-profits. The early HTTPS certs were especially worthless and price-gouging.
> But at least it doesn't have to be a charitable activity covered by non-profits.
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.
> LE isn't primarily funded by non-profits, as you can see from the sponsor list here: https://isrg.org/sponsors/
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.
> > LE isn't primarily funded by non-profits, as you can see from the sponsor list here: https://isrg.org/sponsors/
>
> I mean, Mozilla got the ball rolling
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.
Except for the period before the launch when Mozilla and EFF
were paying people's salaries, including mine, it was
never really the case that Let's Encrypt was primarily funded
by non-profits.
> 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.
That's fair! My primary gripe was about the need for non-profits to step in to begin with. Sorry if I didn't communicate that well.
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.
I agree that it's relatively easy for CAs to validate DNSSEC. I think the fact that they weren't technically required to, despite the sole remaining use case for DNSSEC being to protect against misissuance, is a pretty strong indicator of how cooked DNSSEC is.
It's great to see the free, cryptographically secure, and distributed keyval database that under-grids the entire internet being used to make it more secure. It's too bad lazy sys admins claim that it's not needed and spout a bunch of FUD [1] that is not true [2].
You haven't been a web developer since you posted that article either, since you won't retract silly arguments on your website:
"Government Controlled PKI!"
- Governments own the domains, you just rent them. They can kick your site off and validate their HTTPS certs regardless of DNSSEC.
"Weak Crypto!"
- 1K key sizes were fine given the threat model required cracking one in a year. They have since been increased.
"DNSSEC Doesn’t Protect Against MITM Attacks"
- DNSSEC protects against MITM attacks!
- It's just that most clients don't perform local validation due to low adoption.
- In reality, you are just making the circular argument to NOT adopt DNSSEC because adoption is low.
- There are LOTS more MITM opportunities with HTTPS. We spent a massive effort on cert transparency, yet even Cloudflare missed a rouge cert being issued.
"There are Better Alternatives to DNSSEC"
- There is no alternative to signing domain name data and you point to crypto systems that do something other than that.
- "There are better alternatives to HTTPS: E2E JS crypto with trust on first use"
- What about SSH? I guess we are doomed to run everything over HTTPS and pay dumb cert authorities for the privilege of doing so.
"Bloats record sizes"
- ECC sigs can be sent in a single packet.
- Caching makes first connect latency irrelevant.
On and on and on. These are trivially refutable but you just shut the conversation down and point out instances of downtime ... as if DNS doesn't cause a lot of downtime anyaway.
True, but DNSSEC doesn't need to worry about forward secrecy and it doesn't need quantum protection until someone can start breaking keys in under a year. Hopefully we will find more efficient PQC by then.
> People stopped caring about ulta-low latency first connect times back in the 90s.
They did? That's certainly going to be news to the people at Google, Mozilla, Cloudflare, etc. who put enormous amounts of effort into building 0-RTT into TLS 1.3 and QUIC.
I did a large data analysis of DNS caching times across the web. Hyperscalers are the only ones who care and they fix that with insanely long DNS caching.
I'm not trying to just nitpick you here, but, the message I was responding to said "People stopped caring about ulta-low latency first connect times back in the 90s.".
It seems to me that you're saying here that (1) the hyperscalers do care but (2) it's under control. I'm not necessarily arguing with (2) but as far as the hyperscalers go: (1) they drive a lot of traffic on their own (2) in many cases they care so their users don't have to.
Sorry, the point I was trying to make is that this isn't a problem operationally.
Hyperscalers go to crazy lengths because they can measure monetary losses due to milliseconds of less view time and it's much easier when they have distributed cloud infrastructure anyway. But it's not really solving a problem for their customers. At least when I worked in DNS land ... latency micro-benchmarking was something of a joke. Like, sure, you can shave off a few tens of milliseconds, but it's super expensive. If you want to reduce latency, just up your TTL times and/or enable pre-fetching.
As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. DoH also introduces latency, yet people aren't worried about that being a deal killer.
> As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too.
They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. So I'm not sure this is as strong an argument as you seem to think it is.
> DoH also introduces latency, yet people aren't worried about that being a deal killer.
The engineering effort! ECC solves the theoretical concerns around latency anyway yet we have people arguing that it shouldn't be done. But if it was worth making HTTPS faster to secure HTTP, why not DNS?
You're not going to find this answer satisfying, I suspect, but there are two main reasons browsers and big sites (that's what we're talking about) didn't bother to try to make DNSSEC faster:
1. They didn't think that DNSSEC did much in terms of security. I recognize you don't agree with this, but I'm just telling you what the thinking was.
2. Because there is substantial deployment of middleboxes which break DNSSEC, DNSSEC hard-fail by default is infeasible.
As a consequence, the easiest thing to do was just ignore DNSSEC.
You'll notice that they did think that encrypting DNS requests was important, as was protecting them from the local network, and so they put effort into DoH, which also had the benefit of being something you could do quickly and unilaterally.
I'm not unaware of this and I agree that WebPKI has greatly reduced global risk. New DNS tech takes a lot longer to implement but that doesn't mean we should kill DNSSEC support like the trolls insist upon!
Why would Let's Encrypt not also be interested in safeguarding DNS, SSH, BGP, and all the others? Those middle boxes will have to get replaced someday and we could push for regulation requiring that their replacements support DNSSEC. These long-term societal investments are worth making and it would enable decentralized DNS.
I'm also concerned that none of this will happen if haters won't stop screaming, "DNSSEC doesn't do anything but ackchyually harms security!".
(@tptacek: please stay out of this comment thread)
HTTPS solved a bunch of real world threat models that were causing massive security issues. So we collectively put a bunch of engineering time into making it performant so that we could deploy it everywhere with minimal impact on UX and performance.
Somehow they cause these massive security issues without impacting the 95%+ of sites that haven't used the protocol since it became viable to adopt a decade and a half ago.
It's just a very difficult statistic to get around! Whenever you make a claim like this, you're going to have address the fact that basically ~every high-security organization on the Internet has chosen not to adopt the protocol, and there are basically zero stories about how this has bit any of them.
I run a bunch of websites personally. I have ACME-issued TLS certificates from LetsEncrypt. I monitor the Certificate Transparency logs, and have CAA records set.
What's the threat model that should worry me, where DNSSEC is the right improvement?
>We might see a day when HTTPS key pinning and the preload list is implemented across all major browsers, but we will never see these protections applied in a uniform fashion across all major runtime environments (Node.js, Java, .NET, etc.)[...]
It's actually not safe for clients to perform local validation because a quite significant fraction of middleboxes and the like strip out RRSIG and the like or otherwise tamper with the records in such a way that the signatures don't validate.
No! Because it's totally possible for operating system vendors to flip that switch without requiring every upstream project to adopt key pinning. It's MUCH less infrastructure to upgrade.
You claim in a sibling comment that you have engaged with my points, yet when I talk to you about it you just shut down the conversation.
You really aren't going to respond to any of those points? You stand by your complaint DNSSEC being "government controlled PKI" when TLDs are a government controlled naming system? And your alternative is to advocate for privately owned PKI run by companies with no accountability that are also much more vulnerable to attack?
Campaigning against cryptographically signing DNS records is a weird life choice man.
You're on tilt. It's fine that we disagree about DNSSEC. You seem very angry that you? (it was you, I gather?) wrote a post disagreeing with my post, and I didn't go back and revise my post to capture all the arguments you had that I disagreed with. Sorry, but not sorry. This is just crudding up the thread now though.
If I've said something in this thread that you disagree with, say so and say why (you'll need something better than "I wrote about this 11 years ago and you weren't nice enough to me about it"). Right now, all you're doing is yelling about a post I wrote 11 years ago and haven't cited once on this thread.
Of course, as you know, I stand by that post. But it's not germane to the thread.
I'm upset that your incorrect arguments have gotten so much traction that the internet is a less safe place for it.
> wrote a post disagreeing with my post, and I didn't go back and revise my post to capture all the arguments you had that I disagreed with. Sorry, but not sorry.
You in a sibling thread:
> I feel pretty confident that the search bar refutes this claim you're making. What you're trying to argue is that I've avoided opportunities to argue about DNSSEC on HN. Seems... unlikely.
It seemed like you wanted to have this discussion but I guess not.
> yelling about a post I wrote 11 years ago and haven't cited once on this thread. ... Of course, as you know, I stand by that post. But it's not germane to the thread.
Do you know what comment thread you are in? I complained about FUD and cited your blogpost. This is what this thread is about.
It's OK. I'm working on another post right now, titled "Stick A Fork In It", and you can write a rebuttal, "Pull The Fork Out Of It" and we'll get another chance to do this. We'll see who's more influential. ;)
I'm tickled a the idea that I get to take credit for its demise, though I don't think that's entirely fair. Either way: we're witnessing its agonal breathing. This is an easy call.
I'm not kidding. I've been meaning to write the post for a long time, but some stuff is about to happen to make the prediction clearer. I'm not just talking about the new post to mess with you (I don't know who you are).
Then why the trolling? You claim to be interested in engaging in a substantive conversation or having done so in the past but when I try, you just insult me and announce that my advocacy for DNSSEC has inspired you to go hate on it more.
I think you are confusing me not believing you have a single plausible argument with me trolling you. I promise, when I write stuff about DNSSEC, I'm not thinking about you at all. I learned 10 minutes ago that you were the author of this post you're so wound up about!
Yes, that's a colloquialism meaning "none of this stuff you just wrote has anything to do with the discussion we're actually having". You gave a long point-by-point rebuttal to a post that is not part of the thread. I'm not interested in debating that post with you right now. If it shows up on the front page of HN again, then I'll be happy to go through it with you. Feel free to submit it.
It would make them more secure and less vulnerable to attacks. But lazy sysadmins and large providers are too scared to do anything, in no small part due to your ... incorrect arguments against it.
No it wouldn't? How exactly would it make them more secure? It makes availability drastically more precarious and defends against a rare, exotic attack none of them actually face and which in the main is conducted by state-level adversaries for whom DNSSEC is literally a key escrow system. People are not thinking this through.
That entire post is that you should enable DNSSEC because it's "more secure", and there are no reasons not to.
"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)
You keep waving this blog post from 2015 at me. Not only have we discussed it before, but it was a top-level HN post with 79 comments, many of them from me.
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.
So: I wrote a blog post in January of 2015, and 7 months later you wrote a blog post responding to it in August of 2015, and 10 years later you're still angry that I didn't update my blog post to point to the post that you wrote?
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 advocate for DNSSEC in my personal life and you happen to jump on every DNSSEC HN submission and repeat your claims. So I post a link to my article debunking them. You won't engage in the substantive points here but insist that you have in the past and that you stand by your post. So I suggest your update your post to address my critiques.
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.
I advocate against DNSSEC in my personal life. I write about DNSSEC on HN because I write on HN a lot, and because this is a topic I have invested a lot of time in, going back long before the existence of HN itself. You can find stuff about it from me on NANOG in the 1990s. Your frustration seems like a "you" problem.
I'm sure you can find several of those using the search bar. The argument has gotten a lot grimmer since 2015 --- DNSSEC lost deployment in North America over the last couple years. It didn't simply plateau off and stop growing: people have started turning it off. That corresponds with the success of CT in the WebPKI, with multi-perspective lookup, with the failure of DANE stapling in tls-wg, and with domain hijacking through registrar fixing.
I think you are arguing that DNSSEC is bad, not that people don't use it. And the reason you're providing for why it's bad, is that people don't use it.
I think that DNSSEC is bad. I know that people don't use it (I measure its usage, as you can see upthread). I suspect they don't use it because it's bad. But I guess I'm not as committed to that claim as I am to my first two claims.
No, no, you /refused/ to engage with me when I asked you to address these refutations of your arguments point-by-point. And it's sad that you have helped make weird workarounds more attractive than just doing the work to cryptographically secure how domain names are delegated. It would make the entire stack sitting on top of DNS more secure. Instead we have to have reinvent the wheel for each protocol and outsource security to the TLS certificate vendors.
I feel pretty confident that the search bar refutes this claim you're making. What you're trying to argue is that I've avoided opportunities to argue about DNSSEC on HN. Seems... unlikely.
Thing is, every reported bug can be a bit flip. You can actually in some cases have successful execution, but bitflips in the instrumentation reporting errors that dont exist.
If you get rid of data portability, then isn't it basically a Mattermost server? What is the alternative without going full Nostr where you have to manage all the cryptography yourself?
Either you handle the cryptography for the user AND allow them to DIY it or your target demographic is purely crypto anarchists willing to put up with a shitty UX.
They 100% make excuses for the guy and buy his bullshit. Nothing screams cognitive dissonance like believing that Elon had no idea that his Nazi salute would look like a Nazi salute!
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.