Today's incident isn't a domain binding issue; it's a key mishandling issue. Elevating the role of TLD operators here just increases the number of organizations we have to trust to handle keys properly; worse, as we agree, those new keyholders can't have their authority revoked.

In the main, attacks on the DV process aren't protocol attacks; they're simple ATO attacks on registrars. The DV part of the WebPKI is certainly gross and could be improved, but evidence from the last 20 years says pretty clearly that the DV process itself is not the most urgent risk in the system.

My first hope is that we continue to ratchet security requirements for CAs upwards, and in doing so wash more and more incompetent operators out.

▲

quotemstr an hour ago | parent [-]

My objection is your choosing to build mechanisms that force us to make sure your "we" can "continue to ratchet security" instead of building mechanics that distribute trust and enforce it technology.

I don't care if you write 100,000 or 1,000,000 words: there's nothing wrong with DNSSEC or security that rides on it in principle except that it distributes trust decisions that have been centralized in those objecting to DNSSEC.

It is very bad for the internet to depend for its security on a tiny number of individuals to make global judgements about who's a bad actor.

▲

tptacek an hour ago | parent [-]

Your counterproposal is simply to expand the number of individuals who get to make those global judgements!

▲

quotemstr an hour ago | parent [-]

How so? In the current regime, I can obtain a certificate automatically via ACME. if I control the domain, so to retain control over myexample.com, I need to trust the DNS infrastructure up to my TLD and trust every CA, including the "my secret key is return 4" crowd

In a DANE world, I need only trust the DNS authorities, and there are ways to boost trust in, e.g. the dot-com key management. (Could even go full ring signatures if we wanted.)

Someone over on foo.wtf.lol can't hurt me.

▲

tptacek an hour ago | parent [-]

Two problems with this: first, it describes a spherical cow universe where there is only DANE; on Earth 1, widespread deployment of DANE would add to the number of trusted authorities, not restrict it. More importantly: it assumes a universe in which everyone leaves .COM, which is controlled by the US IC, and somehow finds a TLD that can be trusted both as a domain operator and a CA. When that institution is inevitably suborned by the IC, there will be no recourse, except to migrate like a hermit crab to some new TLD and wait for it to happen all over again.

Meanwhile: this CA is likely to be killed outright for this fuckup.

▲

quotemstr an hour ago | parent [-]

What stops our adding a record that requires DANE and a conventional CA? (Preload it like HSTS, if you'd like, to prevent US IC downgrade attacks if people stupidly configure DNSSEC to fail open.)

This way, fuckups like this CA can't hurt me because they couldn't break DANE and IC couldn't hurt me (more than they can already) because WebPKI would have to approve too.

I don't think the CA death penalty addresses the problem. Just as in the physical world, the death penalty isn't a perfect deterrent.

	▲	tptacek 42 minutes ago \| parent [-]
		The fact that DANE doesn't work on all network paths and it's hard to predict which ones will fail. You have a preference not shared by ordinary computer users, that broken network paths should be loudly broken and not best-effort. If you care this much about your root set, consider having Claude roll you a Chromium or Firefox with a user-controllable set of roots that you ruthlessly prune and manage. Unlike DANE, which simply isn't going to happen for a whole variety of reasons, your personal root program (I gift that term to you if you want the coinage) actually could help people with your preferences.