Comment by quotemstr
16 hours ago
> 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.
The WebPKI semi-routinely kills certificate authorities. The point is that you can't kill a TLD operator.
8 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.
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
3 replies →
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.
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?
DNSSEC creates more operational issues than it solves. It's easy to screw up, which means your domain completely stops resolving when that inevitably occurs. None of the FAANGs use it for their main web sites, so what does that tell you?
It can also be disabled at the whim of anyone operating a resolver, as was seen with Cloudflare during the .de TLD DNSSEC snafu back in May.
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.
6 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.