Interests of the existing PKI industry may be the source of some friction, but the bigger issue is that DANE depends on DNSSEC, which is not widely deployed, and sometimes actively avoided due to its complexity and ease of breaking you site.
Don't get me wrong, I'd love it if DANE, or something similar caught on, but I don't think it is practical until something changes to make DNSSEC (or equivalent) common.
I have a feeling it is "actively avoided" because vendors don't want to lose control of the cert ecosystem. Allowing user to just generate a domain for themselves means it will never get logged in central log and so can't be automatically found by crawlers by the big guys
> If that is the case, why should the server convey the certificate and the OCSP status to the client and defer to the client on the decision not to proceed with the TLS connection? Why shouldn’t the server simply terminate the TLS connection immediately itself?
Why does it matter? You're talking about a scenario that should essentially never happen, who cares about slightly suboptimal performance at that point?
> CRLs only really work efficiently when nobody revokes certificates.
Revocation is an emergency measure, not a routine one. That's ok.
> At this point, why not just use DANE (RFC 6698), store the public keys in the DNS, rely on DNSSEC to provide the necessary authenticity, and use DNS TTL settings to control the cached lifetime of the public key?
Because DNS' multilayered caching makes it notoriously impossible to operate safely or debug. Most large outages already originate in DNS issues; putting the crypto in that layer would redouble it.
On revocation, check out https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Progra... I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke), which is why Let's Encrypt is moving to 7 day certs (so that revocation isn't required, basically https://www.imperialviolet.org/2011/03/18/revocation.html which is mentioned in the article). My impression is CRLs (and by implication current revocation methods) don't work, and browsers are effectively fudging around CAs with custom methods (e.g. allowing existing certs but no new certs from distrusted CAs).
I'm no security expert, but modern bind9 seems to just handle DNSSEC with no issues when I've used it, and given that the "WebPKI" seems is becoming more and more reliant on custom browser code, adopting DANE outside browsers might not be the worst idea.
> Revocation is an emergency measure, not a routine one. That's ok.
At the scale modern CAs operate, even emergency measures (i.e. measures that are an emergency for the party receiving the leaf cert) are also routine for the CA/the party granting the leaf cert.
That is not a problem for certs, you are not changing it every second. And the "impossible to operate or debug" is just plain failse or incompetence
> Most large outages already originate in DNS issues; putting the crypto in that layer would redouble it.
That is also just not true. Also, outage of DNS coz someone fucked up configuration management somewhere is not caused by anything related to DNS, it just so happens DNS is essential so any problem is visible.
I am not against using LLMs, but the author should have validated the contents before posting.