Yeah, ok, but then you need to ask if DANE achieves that. And the answer to that is clearly "no".

DANE never made it past an experimental browser plugin, and as far as I know that isn't even developed any more. In the time where DANE achieved nothing, we got Let's Encrypt, we got CT, and a whole bunch of other improvements to the WebPKI.

DANE technically achieved that, I played around with OpenSSL plugin for DANE back in 2010 (when the . was signed). But yeah, I get your point.

Right now, the path ahead is stapled DANE TLS extension.

Basically, the idea is that you can use simple unauthenticated DNS to get the domain name, just like now. Then you get the complete DNSSEC-authenticated DNS chain for the DANE record as a part of the TLS handshake: https://datatracker.ietf.org/doc/rfc9102/

This seems to be the best of both worlds:

1. We keep DNS as a simple and nimble UDP-based service, without trying to cram the signature in each packet.

2. Since we HAVE to use TLS anyway to achieve any meaningful security, we can just transmit the full DNS chain (up to the root zone!) with signatures easily as a part of the TLS handshake.

3. The client then just needs to validate this chain, and it only needs to have the root zone's key as the root of trust.

4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves.

> 4. The root zone's key changes fairly infrequently (once in a decade), so IoT devices can use it to bootstrap themselves.

This is not true, nor will it be true into the future.

The last root zone KSK rotation was in 2018. I believe the next one is scheduled to start in 2025 and will take 3 years?

> DANE technically achieved that

What exactly did DANE achieve? Replacing CAs? I must've missed something, last time I checked every webpage on the planet was still using CA-signed certificates.

> Right now, the path ahead is stapled DANE TLS extension.

This thing I find really funny. It basically boils down to "we secured DNS. ok, we figured out it doesn't really work. Ok, how about let's stuff our DNS security system into TLS, because over DNS it does not work? Then we have secure DNS!"

Though I've heard this idea many years ago, and it appears deployment is nonexistent, so... probably not gonna happen either.

> What exactly did DANE achieve? Replacing CAs?

The RFC provided a standard, but people choose to ignore it.

> This thing I find really funny. It basically boils down to "we secured DNS. ok, we figured out it doesn't really work. Ok, how about let's stuff our DNS security system into TLS, because over DNS it does not work? Then we have secure DNS!"

Not quite. DNSSEC secured DNS, but it turns out that this by itself is not important in the today's world.

However, we do have a very fragile situation where half the Internet now depends on the goodwill and competency of just one organization for their security (I'm talking about Let's Encrypt).

> Though I've heard this idea many years ago, and it appears deployment is nonexistent, so... probably not gonna happen either.

TLS extension is a fairly new idea, and it only now is starting to get some traction.

This is the second time on this thread you've claimed that a DANE stapling extension is in the works. But it's not: it was proposed and shot down, years ago.

That's factually untrue. RFC 9102 was published two years ago in order to gather experimental data: https://datatracker.ietf.org/doc/rfc9102/ The relevant RFC for DANE is still active, and it hasn't been obsoleted ("shot down").

The major vulnerability of DANE is MITM attacker's ability to "downgrade" attacks into regular PKI in mixed PKI+DANE deployments. So DANE is at worst no better than PKI.

The other problem is the lack of something like certificate transparency for DNS updates and the inability to quickly invalidate erroneous records in caching resolvers, and the general complexity of DNSSEC setup.

People (mostly within the RIPE DNS WG) are working on mitigating that: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-aut... or https://blog.apnic.net/2021/11/02/dnssec-provisioning-automa...

You should tell that to Geoff Huston, because I'm practically quoting him.

https://blog.apnic.net/2019/05/27/dns-oarc-30-bad-news-for-d...

Meanwhile: there will never be anything like CT for DANE and DNSSEC, for at least two big reasons:

1. Browser vendors have no leverage with DNS registrars to force them to deploy it, and that kind of leverage was required to get CT as far as it has been.

2. The DNS top level domains that are required to implement something like CT are controlled by sovereign states, which aren't going to participate in a single global transparency log; in particular, you'd be surprised to see any of the US or UK TLDs conceding to anything like this.

You have links here to DNSSEC automation work, but nothing to any kind of "DANE Transparency", because, so far as I know of, nothing like it has even been meaningfully proposed.

The stapling extension for TLS is a dead letter. Work on it was abandoned a couple years ago, when it finally occurred to the working group that control of a CA would allow you to strip the stapled DANE proof off the handshake, which defeats the entire purpose of the extension. DANE advocates counterproposed a pinning mechanism and got laughed out of the discussion by the browsers, for whom "pinning" is a cursed word.

How would that work if you only trust DANE? And if you have a control over a CA, then you can just issue yourself a certificate for any host anyway, so it's a moot point.

Uhm. It doesn't contradict anything I said. If you MITM the session and strip the DANE data, then you'll be left with no trust anchors.

You can do the same with the regular CA-based trust chain.