Comment by amluto
9 hours ago
For 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.
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.
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.
> 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.
I'm not sure it needs to map out this way. In the last few years people have gotten used to the idea that ACME means that the client interacts directly with the actual CA, but there's another model that at least used to be widespread: certificate brokers. Right now, I tell my ACME cliejnt to get me a Let's Encrypt certificate, and Let's Encrypt validates my request and makes it happen.
But what if I instead tell my ACME client to talk to a broker? The broker would arrange with various CAs for whatever portions of the overall namespace it supports, and it would give me TOS that those CAs find acceptable. And it would then forward my requests to appropriate backend CAs, and those backend CAs would (and would be required to by CA/B rules) validate my request. And I'd get a cert without particularly caring who the backend CA is.
The root stores would treat the backends as fully responsible for validation.
I don't know whether the current ACME model actually supports this very well. The tricky bits I can imagine mostly involve ACME account identification, CAA record details and dns-persist-01. If I authorize my ACME account (held with the broker) for my domain, the backend needs to be able to validate, in a manner that the broker cannot forge except to the extent that it's unavoidable. So if I have account 12345 (just an identifier), then I think the backend should be able to trust the broker's assertion that the client really did convince it (with replay protection) that it's the client for account 12345. But if I have an account where the account itself indicates a public key, then the broker should not be able to forge it.
In any case, I think it's vaguely ridiculous that, right now, the UK government has essentially no say in whether Let's Encrypt may issue certificates for .gov.uk domains. (This is just an example.)
> My company might have 4 domains on different TLDs
Your CA would have a root cert per TLD. Alternatively, we get rid of non-cc TLD (and leave ccTLD only for truly geography-bound organizations, like governments).
Wouldn't that be almost 2,000 root CAs?
Also if it's the same CA operating a bunch of different roots for different TLDs, they're likely to just make the same mistake that impacts them all. Sadly, I can't see anything like this working.
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.