Hahaha. You wish :-p

It's a pretty hard argument to work around: WebPKI certificates should go in the DNS, and also the largest DNS providers might at any moment decide not to validate DNSSEC anymore to get through an outage.

If there's going to be a single point of failure in front of your website, that single point of failure may as well be the only single point of failure instead of having two single points of failure, and it's probably important that people can't hack it.

Nobody had to hack it. A system at DENIC broke, and so Cloudflare turned off DNSSEC validation for all of their users accessing .de. If DNSSEC was actually important for the security model of those users, that would be a huge deal.

If DNSSEC is part of your security model, you want local validation. Not relying on third party resolver that you don't have a contract with.

Beyond that, DNS has the AD bit. If you need DNSSEC secure data (for example for the TLSA record), then when Cloudflare turns off DNSSEC validation, the AD bit will be clear and things will stop working.

Am I the only one who thinks that the AD bit is about as useful as the RFC 3514 evil bit?

We have this elaborate, complex, and extremely fragile cryptographic system behind DNSSEC and we distill it down to one single bit that we carry over unauthenticated links. Why?

At least WebPKI answers the right question: should I trust a particular claim to represent host.domain at the time in the following range? (Of course it defers determining the current time to some unspecified other mechanism.) DNSSEC tries to do everything and cannot survive an upstream error even within the downstream validity window. And yet, despite the fact that most of the spec leans heavily toward failing secure, the actual communication of validation status is entirely unprotected.

I can answer that! Because when DNSSEC was designed, it was believed that serverside compute could not keep up with per-request cryptography. DNSSEC contorts itself in several ways to maintain affordances for offline cryptography, which has been retconned into a security mechanism but was in reality just a bunch of non-cryptography-engineers making a terrible prediction about the feasability of cryptography.

(Source: I'm one of the few weirdos on Earth who has read the mailing lists all the way back to when DNSSEC was a TIS project).

The intention is clearly that the client is a minimal implementation that will only forward a request to a resolver it trusts. The fact that Cloudflare and Google have convinced us all to use Cloudflare's and Google's resolvers is the problem.

DNSSEC and WebPKI both rely on chains of trust. If the problem was that .de's keys expired, you'd have the same problem when Let's Encrypt's keys expired.

The WebPKI works end-to-end all the way to use devices; DNSSEC build an explicit client/server trust model into that. The former is obviously superior to the latter.

Yes, it's also quite damaging to DNSSEC's trust model that the world has transitioned to centralized resolver caches. But the fundamental problem we're talking about with the AD bit wouldn't vanish if 8.8.8.8 and 1.1.1.1 did too; instead, users would be even more reliant on ISP nameservers, which are literally the least trustworthy pieces of infrastructure on the entire Internet.

> If the problem was that .de's keys expired, you'd have the same problem when Let's Encrypt's keys expired.

Even this incident proves that’s not the case.

If LetsEncrypt has a temporary availability issue, my users don’t notice unless it spans longer than my need to renew a cert.

If LetsEncrypt has a CA cert expire, I can get a cert from another provider.

If DENIC’s DNSSEC records break, either due to an operational error or an expiry issue, my .de site becomes inaccessible and my users see a DNS lookup failure. My only option is to hope resolvers do what Cloudflare did, or move my site to a new TLD and just pray that TLD never has the same problem.

This is a non sequitur.

Yes, it's a crappy outcome, but endpoints can still choose to enforce this. Further, it's not a persuasive argument against more DNSSEC usage, since if there was more DNSSEC usage then resolvers would be more reluctant to disable it.

Probably the most common reason to use DNSSEC is to check a box on a list of compliance rules. And I don't think this will change anything for people who need DNSSEC for compliance.

There's no commercial compliance regime that requires DNSSEC (FedRAMP might be the only exception --- I'm uncertain about the current state of FedRAMP DNSSEC rules --- but that makes sense given that DNSSEC is a giant key escrow scheme.)

FedRAMP requires it, although like many requirements, you may be able to get out of it if you have a good reason and/or your sponsoring agency doesn't care about it.

There are also some large businesses that require, or strongly pressure SaaS providers to use DNSSEC. You can often contest that, but if you have DNSSEC, that's one less thing to argue about in the contract.

Which businesses are those? (I ask because if they're North American, I have a pretty good sense of which large North American businesses even have DNSSEC signatures set up, and it's not many; small enough that you can easily memorize the list.)

Probably the most common reason to use TLS is to check a box on a list of compliance rules. Is that bad?

Do browsers even load non-HTTPS sites anymore without a massive warning?

Yes, they do.

Yeah just ignore the big "not secure" warning in the URL bar

I just checked it. You mean the very small open padlock icon? The era of browsers warning loudly about HTTP was a decade ago, it got reversed due to pushback.

Well I checked both Chrome and Firefox on mobile and my desktop and they were all much more obvious than just an "open padlock". They both said "Not Secure" and in Firefox it was bright red text. Also in incognito mode Chrome refused to even open the site without a full screen warning. They all make it super clear non-HTTPS sites are not secure so I'm not really sure what your point is?

neverssl.com works fine for me, only a small warning in the place where the padlock usually is, that no-one checks anyway.

The browser would be very unhappy with an <input type="password"/> on a non-TLS site (localhost excepted). HSTS would trigger the "massive" warning and refuse to load the site, however.

It's more pronounced on desktop

Ah yes I think the HSTS issue is what I was thinking of

browsers pushed it, not compliance

I found another reason... MS365 require DNSSEC to be enabled if you want DANE for TLS-enforced SMTP. You could also use MTA-STS.

As far as I know, the DANE spec (RFC 7671) requires DNSSEC to be enabled, while MTA-STS does not.

MTA-STS was standardized explicitly to support the (nearly universal) use case of mail providers without DNSSEC. Even O365, which ostensibly supports DANE/DNSSEC for email security, does so only for select customers and not for ordinary ones (go look for the TLSAs).

OTOH there was recently a DNSSEC-saved-the-day piece of news: https://incrypted.com/en/dns-attack-on-eth-limo-was-stopped/

That only worked because the attacker didn't understand dnssec. If they had unsigned the domain first and then hijacked it they would have succeeded.

I haven't been able to find any cases of genuine dns hijack attacks in the last few years. Would love to know if anyone else can?

Only about 40% of the crypto companies seem to use dnssec. Seems like a target rich environment.

I doubt it. The root cause of this was a root server misconfiguration or bug. It happened to DNSSEC records this time, which is a pain, but next time it might as well flip bits or point to wrong IP addresses instead.

Paradoxically, resolvers wouldn't have noticed the misconfiguration if it weren't for DNSSEC.