> If DNSSEC/DANE is deployed, and some clients cannot make use of it because they are shitty, why hold back the non-shitty clients that can deal with DNSSEC/DANE? Just because 100% coverage for all clients isn't possible doesn't mean we shouldn't try to move the ball forward.
Because that's only the first step. After that you have to solve all the problems WebPKI has already solved for itself.
Two primary things - the ability to remove trust anchors and visibility into issuance. Neither of which are in any means doable or solved with DNSSEC at this point in time.
You just rebutted a comment nobody made, and ignored the comment that was made. Like it, and the article itself, says: the DNS PKI hasn't addressed revocation and visibility. The Web PKI has: CAs are required to submit to CT logs, and the browser root programs have killed some of the largest commercial CAs for noncompliance. Neither of those is possible, or will be possible, in the DNS PKI.
> Neither of those is possible, or will be possible, in the DNS PKI.
Transparency logs for domain issuance is completely possible, it just requires some engineering and deployment. Remember that HTTPS was in use for decades before CT logging of certificates became mandatory.
More importantly, though, we need to be clear about what "noncompliance" means. In the web PKI, it means a CA issuing a certificate for a domain that the requester doesn't control, but the equivalent for that in the DNS PKI would be TLD .foo publishing data for a domain example.bar which is not an attack at all, because no one would care what .foo thinks about a .bar domain.
So, rather than relying on browsers being brave enough to kill a large provider (and we need to be honest with ourselves about how much leeway browsers would give to Let's Encrypt if they ever suffered a catastrophic security breach), the DNS PKI simply isn't vulnerable to this problem, because TLDs can't issue certs for domains that aren't registered under them.
No, they’re not. They’re only possible in the Web PKI because of the coercive power the browser root programs have over CAs. No such influence exists in the DNS.
Mozilla will dis-trust your CA if you try to evade CT. It can’t revoke .io.
Because that's only the first step. After that you have to solve all the problems WebPKI has already solved for itself.
Two primary things - the ability to remove trust anchors and visibility into issuance. Neither of which are in any means doable or solved with DNSSEC at this point in time.