alt Hacker NewsFor all that DNSSEC is crap, DANE would at least mean that a domain is only vulnerable to failures of the authorities relevant to the domain.
Meanwhile there are two less invasive changes that really ought to happen:
1. A clean way for things like curl and Python to start checking CT logs like Chrome does.
2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.
Replies
1. They could do this now, the implementation exists publicly, but I think it would be better at the OS level like upki for revocation: https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki...
2. I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.
This is everyone's first pitch for why DANE would improve the WebPKI. But it doesn't make sense as risk management. It assumes that the most important TLD operators, .COM especially, are trustworthy. But we know .COM is not trustworthy, at all. And it gets worse when you leave the US. In much of the world, state organizations have explicit de jure control over all the popular top level domains.
This is a simple point but there's something subtler underneath it. Strict name constraints are an obvious seeming improvement to the WebPKI. I like them too. but eMudhra isn't just an Indian sovereign CA; it's an important global commercial vendor. On the other thread about this incident, 'agwa pointed out that an eMudhra subsidiary does a lot of the certificates for US universities.
You're still going to end up with the same concentrations of risk, because large CAs are going to want to issue in the most popular domains.
Don't get me wrong, anything that ratchets up the difficulty of running a CA (without unduly burdening LetsEncrypt) is a positive as far as I'm concerned. I'm just saying these are hard problems.
1 already exists. You don't check the ctlogs; the ctlogs as their signed timestamp to the certificates. All you need to verify that a certificate has been published is to verify the timestamp signatures.