I’ve got those choices if I use DNSSEC for my trust, correct. Or I use the existing system, where if a CA misbehaves, we boot them out of the browser trust stores and site operators don’t have to change anything.
And yet when attackers want to misissue certs for small sites (for big sites, misissuance is detected automatically and gets CAs killed), they don't exploit vulnerabilities that DNSSEC defends against. Why is that? And given that's the case, why pursue DNSSEC?
And how is any of this, any of it all, relevant in a world where registrars can simply speak RDAP to CAs? If you believe the problem is that the Internet will (to use your turn of phrase upthread) crumble away unless we secure the DNS for domain validation, why should we forklift out the entire DNS to do so, when we can just get a small group of organizations to deploy RDAP, something they're planning on deploying anyways, and then add that to the 10 Blessed Methods?
Because the DNS as it is allows for the potential to do something similar (by getting a CA to accept fraudulent DNS response, leading them to issue a cert,) without someone seizing control of a domain otherwise.
Securing the DNS (a) doesn't fix the underlying problem for TLS (as you can see by the last 2 waves of CA-missuance takeover attacks, neither of which relied on wire-level DNS hijacking) and (b) adds nothing to any secure protocol, which already has to do end-to-end verification today. Despite that, DNSSEC is already the most expensive proposal we have on the table today, requiring every major site and every major piece of software to upgrade or reconfigure.
Deploying RDAP and adding it to the CA/B Forum Blessed Methods gives CA's themselves an end-to-end ability to validate domains, decisively solving the DV problem, and doesn't require any of that expense.
Explain to me again why we should choose the former over the latter?
Except there has to be a crypto proof why Google owns google.com not me. That means we need to secure dns. Then why need CAs at all ? Whats the point ?
Of course they can. There is literally no legal or otherwise difference between Verisign and .com. Chrome can do whatever it want, cause its Google's browser not .com's.
In case when .xxx becomes dishonest, you can just move to your own gtld or .more-trustable tld. In current system, there is no concept of ditching a CA. If a CA decided to missmap a name and you are too small, you are fked.
> it’s actually 1, or 1 AND 2
No you can have DNSSEC without CAs. I have explained that already without changing much of the tls. Basically example.com DNSSEC key become CA for example.com. example.com then would create a tls cert in the usual way. No pain.
“You can just move to your own <other TLD>” isn’t even remotely plausible. Any site with worthwhile traffic isn’t going to just forklift to a new TLD and convince all their users to switch over. Imagine if .com was considered untrustworthy and suddenly every user in the US had to use google.othertld, facebook.othertld, etc.
Again if that's true then the game is up, because the USG obviously controls .COM; they theatrically demonstrate that every time they take down a piracy site. But, spoiler! The game turns out not to be up.
The former, for several reasons, among them the fact that those actually aren’t the options (it’s actually 1, or 1 AND 2), and the fact that Google can’t end .com they way they did Verisign.
But feel free to ask the relevant team at Google, who will give you the same answer.
So you’re already trusting the DNS, whether protected with DNSSEC or not, in the existing system.