indolering

> DNSSEC only protects the name lookup for a host, and TLS/HTTPS protects the entire session.

It only provides privacy, it doesn't verify that the resolver didn't tamper with the record.

>to the point where the root keys for DNSSEC could be posted on Pastebin tonight and almost nobody would have to be paged.

This would very much be a major issue and lots of people would immediately scramble to address it. The root servers are very highly audited and there is an absurd amount of protocol and oversight of the process.

Okay, but after this I have to go back to work.

You got a point: 1k isn't great and of course mainstream cryptographers will advocate for higher. That doesn't change that it's still acceptable within the existing security model nor that better alternatives are available. The cryptographic strength of DNSSEC isn't a limiting factor that fatally dooms the whole project. We have to upgrade the crypto used in large-scale infrastructure all the time!

And yes, uptake of better crypto is poor but I find chicken-and-egg arguments disingenuous when coming from someone who zealously advocates to make it worse. Furthermore, your alternative is no signing of DNS records. Find me a cryptographer who thinks no PKI is a better alternative. I know DJB griped about DNSSEC when proposing DNSCurve, which protects the privacy of the payload but not the intergrity of the payload.

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 worked at a DNS provider, does that count?

The benefits are huge: there are lots of attacks that DNSSEC trivially prevents and it would help secure more than just web browsers.

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.

Yup.

You are going to complain that the key sizes are too small despite the guidelines being updated a long time ago. Then you will argue adoption of larger keys sizes is to low. Then you will argue that we should just not sign domain name authority delegation records at all (i.e. DNSSEC) and that we should abandon shoring up authenticated DNS because there is no adoption.

You have any cryptographers that are satisfied with unauthenticated name server checks?

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.

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.

> You're on tilt.

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.

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.

RSA is still fine given that you can't break it in a year and we aren't worried about forward secrecy.

Also, I worked for a DNS company. People stopped caring about ulta-low latency first connect times back in the 90s.

You are clearly very proud of your work devaluing DNSSEC. But pointing to lack of adoption doesn't make your arguments valid.

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.

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.

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.

Bad arguments and FUD when it was being rolled out. Sysadmins also don't want to touch working infra code, you can see that with AWS lagging on IPv6.

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!

As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.

Sorry, I thought my edit was fast enough.

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.

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.

Boy, how would cryptographically the ROOT of the internet make it more secure? Right here dude: https://easydns.com/blog/2015/08/06/for-dnssec/

Which is really unfortunate, since it's pretty easy to do.

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].

[1]: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ [2]: https://easydns.com/blog/2015/08/06/for-dnssec/

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, 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.

What a waste.

> DNSSEC is moribund.

You’ve clearly put a lot of effort into limiting adoption. I’d really value your thoughts on this response to your anti-DNSSEC arguments:

https://easydns.com/blog/2015/08/06/for-dnssec/

Glad to see this finally getting some much needed love and attention!

Being able to detect these issues is just as important as preventing them.

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.