> Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.

Had we been using DANE instead of WebPKI, the response to this sort of compromise would be "aw, shucks, someone proved to be untrustworthy and they're in such a critical role in the ecosystem that there's no way to route around this DNS provider being untrustworthy."

▲

eqvinox a day ago | parent [-]

> aw, shucks, someone proved to be untrustworthy and they're in such a critical role in the ecosystem

You mean until the DNSsec key rollover completes and they're no longer in that role?

As opposed to what we have now, an indefinite period where crappy non-updated devices will still accept these certs and nothing can be done about it?

The Web PKI works great for browsers. Everything else, not so much.

(To be fair, the crappy devices¹ would probably fail to deal with the periodic DNSsec root key rollovers. But at least that's a fail-closed.)

¹ a label that includes older versions of systemd-resolved, for whatever that may mean

▲

tptacek a day ago | parent [-]

DNSSEC key rollovers don't change who has custody of the keys. They're not a magic spell that fixes stuff like this. It is closer to the truth that DNSSEC is limited to recovery from incidents like this to doing rollovers, rather than immediate revocations. Rollover is not something that makes DANE more attractive here.

▲

account42 13 hours ago | parent | next [-]

So you're upset that Google et al can't dictate who has authority over .com with DANE? Because yes, that's how DNS is supposed to work and also how domain validated web PKI works because that's just a glorified DNS consensus system which happens to give bullying power to browsers and root store operators. It would be up to ICANN (or countries for ccTLDs) to determine if the issue warants replacing the operator.

	▲	tptacek 7 hours ago \| parent [-]
		No, I think that state-controlled naming authorities shouldn't control cryptographic keys, for the reasons laid out on this and numerous other threads about DANE. You know you're in trouble when you see people talking about "bullying" from the browsers, who are the only reason we have certificate transparency and don't have CAs literally selling root certificates to big companies to run their own private CAs.

▲

eqvinox a day ago | parent | prev [-]

I don't think I understand what you're trying to argue here; if you can't find a usable registrar for your domain… you can't really use that domain anyway, can you? They can just break it. But… let's not get into yet another DNSSEC/DANE discussion.

▲

tptacek a day ago | parent [-]

I'm not sure I see what this has to do with how the DNS operates, beyond observing that key rollovers are not a reasonable response to incidents like this.

▲

eqvinox 8 hours ago | parent [-]

I'm not connecting at all on this discussion because I don't understand what entity/role in DNS/DANE is the equivalent to eMudrah that is to be distrusted and can't / has to deal with compromised key material. It could be either the registrar or the TLD operator. The former you can switch to another one. The latter just makes the entire TLD unusable no matter how you spin it and whether you use DANE or not. Is there some third role you're considering here?

	▲	tptacek 7 hours ago \| parent [-]
		This seems simple. Nobody is switching domain names as a result of this eMudhra thing; they're just going to switch CAs, when eMudhra is murdered by the root programs. But switching domain names would be the only thing you could do if a DANE key was mishandled.