alt Hacker News> DNSSEC can be trivially used with DANE to protect the entire session. The browser vendors quite consciously decided to NOT do that.
100%. The reasons why are explained in some detail here: https://educatedguesswork.org/posts/dns-security-dane/. The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetuity.
> This is the outcome of browser vendors not caring at all about privacy and security.
This is false. The browser vendors care a great deal about privacy and security. Source: it was my job at Mozilla to care about this, amongst other things. It may be the case that they have different priorities than you.
> You're saying that to provide service for anything over the Web, you have to publish all your DNS names in a globally distributed immutable log that will be preserved for all eternity?
Well, back when people were taking DNSSEC and DANE more seriously, there was a lot of talk of doing DNSSEC Transparency.
> And that you can't even have a purely static website anymore because you need to update the TLS cert every 7 days? This is just some crazy talk!
This is hyperbole, because nobody is forcing you to update the TLS cert every 7 days. It's true that the lifetimes are going to go down to 45 days eventually and LE offers 6 day certificates, but those are both optional and non-default.
Moreover, the same basic situation applies to DNSSEC, because your zone also needs to be signed frequently, for the same underlying reason: disabling compromised or mississued credentials.
> The TL;DR is that by the time DANE was created the WebPKI already existed and was universal and so adding DANE didn't buy you anything because you still were going to have to have a WebPKI certificate more or less in perpetuity.
Yet somehow they managed to wrangle hundreds of CAs to use the CT logs and to change the mandated set of algorithms.
> Well, back when people were taking DNSSEC and DANE more seriously, there was a lot of talk of doing DNSSEC Transparency.
And this would have been great. But it only needs to make transparent the changes in delegation (actually, only DS records) from the TLD to my zone. Not anything _within_ my zone.
And tellingly, the efforts to enable delegation in WebPKI are going nowhere. Even though X.509 is supporting it from the beginning (via name constraints, a critical extension).
> This is hyperbole, because nobody is forcing you to update the TLS cert every 7 days.
The eventual plan is to have shorter certs. 47 days will be mandated by 2029.
It also doesn't really change my point: I can't have a purely static server anymore and expect it to be accessible.
> Moreover, the same basic situation applies to DNSSEC, because your zone also needs to be signed frequently, for the same underlying reason: disabling compromised or mississued credentials.
That's incorrect. I've been using the same key (inside my HSM) since 2016. And I don't have to update the zone if it's unchanged. DNSSEC is actually _more_ secure than TLS, because zone signing can be done fully offline. With TLS, the key material is often a buggy memcpy() away from the corrosive anonymous Internet environment.
So you can rotate the DNSSEC keys, but it's neither mandated nor necessary. The need for short-lived certs for TLS is because there's no way to check their validity online during the request (OCSP is dead and CRLs are too bulky). But with DNSSEC if at any point my signing key is compromised, I can just change the DS records in the registrar to point to my updated key.