Unfortunately the best solution there was for this problem was probably HPKP, which fell out of favor years ago. Would be nice to have some kind of solution for this some day; I think it would compliment CT very well.

CAA plus DNSSEC also provides significant defense against some types of attacks on domain validation.

No, because the CAA record only has to be in place at the time of issuance, rather than the whole lifetime of the certificate.

Even if the semantics of CAA were changed, the challenges described in paragraph 3 of this post would apply: https://www.imperialviolet.org/2015/01/17/notdane.html

Wouldn’t that be an obvious quick win?

Sure, gmail.com might be excluded, but its still a massive hole for a few reasons.

This would affect ANY email provider who offers public email addresses. While I agree gmail.com is probably excluded (and maybe this doesn't bypass CAA -- maybe it does) there's a whole additional surface of anyone who has an email at any big enterprise getting a certificate for their domain.

Even if I work at google.com, therefore have a google.com email, I should absolutely not be able to get a certificate for google.com just by getting an email at that company.

I doubt it's even /that hard/ to buy an email account at a big company like that in the underground world, it seems like they are valuable generally and any company with 200k employees is going to have some leaks. This massively increases the attack surface of a simple leaked email account (which might otherwise have very little or no access).

Crazy crazy oversight that has huge implications and is so easy to carry out that I would not be surprised if this was actually exploited by bad actors.

> Issuing a Google certificate is a good way to get your whole CA killed.

Surely what happened here is a good way to get your CA killed? The linked bug seems pretty bad.

[dead]

Maybe?

I wouldn't assume that the bug doesn't bypass CAA checking.

Very important question to answer.

Yeah - unless you're an actual SSL.com customer, in which case your CAA records would allow it. That's a much smaller blast radius at least.

> Out of an abundance of caution, we have disabled domain validation method 3.2.2.4.14 that was used in the bug report for all SSL/TLS certificates while we investigate.

I think they have already addressed the bug.

This method may be more popular than you'd think, since it only requires the TXT record to be published once, whereas using the DNS method requires periodically updating the DNS record. Yes, that can be automated or delegated, but for a legacy/manual/dysfunctional organization, email to TXT record contact is an easy alternative to the now-banned email to WHOIS contact method that they were likely using previously.

You could at least narrow it down to certs with multiple domains, since it sounds like the email domain was added as an additional domain.

Random third parties can't verify if domain validation was performed properly; only the domain owner knows. Which is why domain owners should monitor Certificate Transparency logs: https://certificate.transparency.dev/monitors/

> When was the last time you had to bypass a cert warning because of "CA store wars" (whatever that means)?

Essentially all the time for the last 10 years...

Did you ever try to deploy a website with a certificate from a non public CA? Like, say, your company CA?

If you want it to be valid for Java users, you will have to store your CA cert on the Java trust store.

Want it available for users of Firefox ? Store it in the OS certificate store.

Want it available for Chrome users? Store it in the Chrome certificate store.

Want it available for Python users? Add it to certifi.

And so on.

No single piece of software validating certificates agree on a single CA certificate store.

So, essentially, no company out there supports all these stores, and you just train users to bypass these warnings.

> What examples can you give for public CAs giving certs to "whatever"?

There have been dozens of CAs removed from widespread trust stores for failing to do proper diligence or reporting leaked keys.

Not only that, but essentially I never myself to do any kind of diligence for whatever certificate I requested from public CAs beyond proving I had TXT records update powers at some point in time.

I'm not even mentioning fortune 500 websites running with expired certs.

Unclear who revoked that but I think it likely was the reporter who discovered the bug. They only needed it issued & logged as evidence, and would be good practice to revoke immediately.

Nope, it's not the same. The point of having the Registrar involved is to side-step the problem of validating a cert request is allowed to request the cert. All the CA validation methods are supposed to be verifying your authorization to request a cert, but they don't do that.

They instead verify your authorization to control DNS records, or IP space, or an e-mail address. And there's dozens of exploits to compromise each of those. And they can be chained. And they can be CA-specific.

That's not domain authorization, and each of those verification methods lacks cryptographic authentication. Only the Registrar controls the domain, so that is the only way to know that the request is genuinely authorized. We're playing a game of telephone, it's not secure, and it's unnecessary. Just get the registrar involved.

That's a much simpler problem to solve than the current one. One attack vector to cover, one set of organizations, one trust list. It's definitely no worse than our current predicament.

Basic math shows how much safer the new model would be:

  - Assume there are 350 CAs, 3 validation methods, and 12 kinds of exploit per validation method (there are more in some combinations but for simplicity I'll say 12).
    (350 x 3 x 12) leaves *12,600* possible attack vectors.

  - Now assume there's 2,650 domain registrars, 1 validation method, and 1 kind of exploit.
    (2650 * 1 * 1) leaves *2,650* possible attack vectors.

So 4.75x fewer possible attack vectors.

Add to this that with only 1 validation method and 1 feature to support, that's way less code, which means much fewer bugs.

Add to that a cryptographic chain of proof that the key of the domain owner was used to sign the request all the way, which we don't have today.