DANE replaces this system with one that has the same basic cryptographic properties, but in which you can't eject bad actors --- or even monitor them with a mandatory transparency log. It's strictly worse than this.

▲

toast0 3 hours ago | parent | next [-]

WebPKI can't eject the bad actors that would cause trouble in DANE either. If your TLD conspires against you, they can certainly establish domain control and get a properly issued WebPKI cert.

Visibility through Certificate Transparency logs would at least make it a matter of record that it occurred, though.

▲

tptacek 2 hours ago | parent [-]

The WebPKI semi-routinely kills certificate authorities. The point is that you can't kill a TLD operator.

▲

toast0 an hour ago | parent [-]

> The point is that you can't kill a TLD operator.

I agree, you can't kill a TLD operator. But WebPKI relies on TLD operators to establish identity, so I don't see what we gain from WebPKI, other than mandatory CT logs, and not having to faff about with DNSSEC :P ... both of those are pretty valuable, of course.

I'll put it another way: why do we want a CA to tell us that someone controls a domain, when the TLD could tell us? The TLD is authoritative with regard to who controls a domain; CAs can only report on what they have observed.

▲

tptacek an hour ago | parent [-]

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 17 minutes 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 3 minutes ago \| parent [-]
		Your counterproposal is simply to expand the number of individuals who get to make those global judgements!

▲

eqvinox 5 hours ago | parent | prev | next [-]

> It's strictly worse than this.

Maybe if people implemented name constraints and the CA/B forced CAs to use them. But not as it is; unconstrained sub-CAs are a scourge on the Web PKI.

▲

agwa 2 hours ago | parent | next [-]

Name constraints are intended for organizations which want to issue publicly-trusted certificates for their own domains. Name constraints are already widely supported and name constrained sub-CAs exist for this purpose in the WebPKI.

eMudhra is not such a case. They are a root CA that issues certificates to the general public all over the world. In fact, they are now the preferred vendor for numerous US universities via InCommon[1]. There is no way to meaningfully name constrain them.

[1] https://incommon.org/certificates

▲

tptacek 2 hours ago | parent [-]

Can you share any insight about how an Indian CA became the preferred vendor for US universities despite the existence of LetsEncrypt? I know this is kind of a dumb question.

	▲	agwa 2 hours ago \| parent [-]
		I had a friend who worked in university IT and I got the impression that there was a strong desire to use "supported" products (in general, not just certificates) even if it cost money and was worse than free alternatives. Interestingly, InCommon used Sectigo prior to this year. I'm guessing eMudhra costs less.

▲

tptacek 4 hours ago | parent | prev [-]

I like constraints too, but listen carefully to EKR and 'agwa on this, because a lot of things that seem like straightforward fixes are much more complicated in reality. The most important thing I want from the WebPKI is expensive entry and the death penalty for fuckups, and I think we basically have that now.

▲

quotemstr 7 hours ago | parent | prev [-]

It has the property of aligning cryptographic authentication with the domain name hierarchy. Yes, you trust the hierarchy. You trust LE too, so what? We need to move away from any authority being able to authenticate anyone, and DNS naturally aligns with the goal.

You've been vocal for a long time against DNSSEC deployment too for no discernable reason.

Why are you against every single thing that tries to make DNS useful for securing anything?

	▲	tptacek 5 hours ago \| parent [-]
		Do the words "no discernible reason" just mean something very different to you than they do to me? Because I've written somewhere in the vicinity of 100,000 words about the problems of DNSSEC over the last 20 years. My written DNSSEC critique predates HN itself. This particular issue has nothing to do with "aligning authentication with the name hierarchy". The exact same thing that happened to EMudhra could happen to any TLD operator. The difference is that we have essentially no recourse when that happens, and far less ability to detect malfeasance.