← Back to context

Comment by account42

13 hours ago

> 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.

>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.

  • 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.

    • 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.

      7 replies →

> 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.

  • 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.

    • 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.

      9 replies →

    • > 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.

      5 replies →

    • 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?

      8 replies →

  • 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.