> What are the consequences?

> An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.

And how many more times do we need to read this before we replace Web PKI with a system that isn't as completely insane?

We already have a functioning system for delegating domain ownership in a hierarchical fashion where compromises are limited to only the subtree under the compromised entity. Let's start using it for domain validation sooner rather than later.

▲

vlan0 6 hours ago | parent | next [-]

>And how many more times do we need to read this before we replace Web PKI with a system that isn't as completely insane?

You say this like it's easy and simple and we are simply not choosing to do so.

▲

__MatrixMan__ 5 hours ago | parent [-]

It's been obvious for a while now that root-of-trust schemes create juicy targets, and that juicy targets attract all sorts of bad behavior that wouldn't be economical if we used a web-of-trust.

Building a web-of-trust scheme that works might not be easy, but also it's not like we've been trying exceptionally hard lately either.

▲

jcranmer 4 hours ago | parent [-]

Web-of-trust doesn't work. Even before the PGP web-of-trust broke down several years ago, analyses of how the web-of-trust actually ended up working out showed that it basically boils back down to CAs: people rely on a few highly central keys to do most of the signing rather than signing keys themselves, and these keys effectively function like CAs.

The broader issue is that users don't want to (and probably don't have the ability to) actually make any trust decisions; they much prefer to delegate all of the decisions on trustworthiness to somebody else. The PKI root CA system does have its flaws, but on the whole, I suspect that people like Mozilla are better stewards as to whether or not the person vouching for somebody else is trustworthy than the average or even the above-average user.

▲

__MatrixMan__ 4 hours ago | parent [-]

Web of trust has been working between humans for over a million years. If we've failed to make computers do it, it's probably just for lack of trying.

To your second point, that might be true in a world where the consequences of making a bad trust decision was some kind of hassle related to changing passwords or reporting your cards stolen. But we seem to be moving towards a world where it lands you in a detention facility or some other dire consequence. I think that sooner or later, users are going to realize that they want that control and will be willing to do the corresponding trust hygiene work. Besides, isn't making that kind of work easy the point of technology? We just need to do better re: making it usable rather than investing in systems we know to be unsafe.

▲

eqvinox 2 hours ago | parent [-]

Humans are generally considered to have been around for only ca. 300'000 years.

Also, the interpersonal web of trust is IMHO quite clearly failing in the age of mass media, and not just recently.

	▲	__MatrixMan__ an hour ago \| parent [-]
		Sure, but what do we do from here? Attempt to augment it with technology so that it starts scaling again, or give up and replace it with something centralized?

▲

quotemstr 6 hours ago | parent | prev [-]

> We already have a functioning system for delegating domain ownership in a hierarchical fashion

Well, yeah. DANE should have won. NameConstraints would be nice tooo, but who's going to make CAs use it?

And FFS, clients could at least check CRLs once in a while.

▲

tptacek 6 hours ago | parent | next [-]

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 an hour 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 an hour ago \| parent [-]
		The WebPKI semi-routinely kills certificate authorities. The point is that you can't kill a TLD operator.

▲

eqvinox 4 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 an hour 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 an hour 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 an hour 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 2 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 5 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 4 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.

▲

ekr____ 5 hours ago | parent | prev [-]

People have debated DANE endlessly here, so I'm not sure how much more I have to add at this point. However, browsers, at least, do swiftly handle revocation for CAs, as indicated in this comment: https://news.ycombinator.com/item?id=50167244. They also handle EE revocation to varying extents, with Firefox having complete coverage and other browsers having partial coverage.