Comment by cyberax

> I'm not sure I see the connection here. What I'm saying is that the benefit for sites to adopt DANE is very low because as long as there are a lot of non-DANE-using clients out there they still need to have a WebPKI cert.

I find this argument laughable. Adding support in just 4 browsers and to iOS/Android would have moved something like 99% of traffic to DANE. The long tail could have been tackled incrementally. A lot of it doesn't even care about validation anyway.

> Re: your broader point about static sites, I don't think you're correct about the security requirements. Suppose for the sake of argument that your signing key is compromised: sure you can change the DS records but the attacker already has a valid DNSSEC record and that's sufficient to impersonate you for the lifetime of the record

I said it before, and let me repeat it: long TTLs for DNS records are an operational malpractice at this point, even disregarding DNSSEC. Having a TTL more than 15 minutes provides no practical advantages outside the root zone.

> I agree with you that one advantage of DNSSEC is that that signing can all be done offline and then the data pushed up to the DNS servers, but it's still the case that something has to happen regularly. You've just pushed that off the TLS server and into the DNS infrastructure.

Why? What additional security do I gain from periodic ZSK/KSK rotations? Especially if I keep the private key material offline (in an HSM), which is not possible for TLS, btw.

> In the WebPKI paradigm, the server has to regularly contact the CA to get a new certificate. [1]

Except that ACME does not enforce the private key rotation. I think most of infrastructure now rotates them, but the old key will still be valid for the duration of the compromised cert. And unlike 1-2 hour typical DNS TTLs, the WebPKI certs will be valid for weeks/days.

So yeah, I don't see any reason why WebPKI is _technically_ superior. I can see it being superior because of the browser vendors' support.