Why aren't SSL certificates tied to something like DNSSEC where a CA is responsible only for one tld? Since domain ownership is enough to get a certificate signed anyway, that wouldn't change security properties.
(2) Because DNSSEC is a nightmare to deploy. Leaving the IANIX-type operational stuff aside, it doesn't work on all network paths; plenty of middleboxes freak out when they see DNS packets with DNSSEC records in them. People see this and want a best-effort system that uses DNSSEC in the majority cases where it does work, but now you have a downgradable, strippable security protocol.
(3) eMudhra is being murdered by the root programs as we speak, and when they're gone all we'll remember them for is as a WebPKI incident. The WebPKI itself will continue to function and nobody will care. That can't happen with .COM or .CO.UK or .IO; there's no accountability for those registry operators at all, let alone transparency logs to track what they're doing.
As such, DANE would not add more issue here;
DNSSEC is easy to deploy (of course, you need to know your work, which is rarely the case). Legacy-first mindset is not really productive;
That's is correct, but on the other hand, incorrect: as a .com registry, I can:
- fake the CAA records
- fake the DCV records
- make any CA sign any certificates
This is more than twenty-five years after DNSSEC standardization commenced in earnest (counting from the bis protocol).
I completely agree that the tooling is questionable, and that the protocol is meh, but in this case the monitoring noticed the problem yet humans did not notice (or get) the alert.
Who? Companies whose audiences are certain kinds of corporations?