Given all of the failed CAA lookups of late (which have usually been signs of larger DNS issues) and questions/situations involving incorrect CAA records (which are far less frequent), I got to thinking about "do not kick me" signs. Specifically, do semi-standardized security efforts involving voluntary compliance with preferences actually work? I can't help but think of the (IMO useless or even counterproductive) Do Not Track header. Granted, there are far fewer CAs than webservers and trusted CAs have a reasonable motivation to comply. I'm just not a fan of "optional" security efforts. What do you all think?
The CAA record has RFC status? I'd say that's quite standardized?
Also, the comparison with the DNT header doesn't work IMO: CAA checking by CAs is mandatory since 8-Sep-2017. See section 126.96.36.199 of the Baseline Requirements. There is no mandatory aspect of the DNT header, so the comparison doesn't hold.
If I'm implementing a CA, I can certainly ignore it. Then again, I can also issue certificates in any way I want. Trust is the key, I think. Who is the kingmaker though?
The CA/Browser Forum?
If you don't abide to their rules, your CA is as much worth as me running a CA with just a few OpenSSL commands: unsupported in all major browsers.
So if as a trusted CA you have a correct implementation to verify domain name control, what then is the point of having a CAA record? In essence, doesn't the practice of verifying domain name control make the CAA record entirely redundant? If I hijack your DNS, I can just remove the CAA record anyhow.
Hijacking DNS is not necessarily and all or nothing prospect. Different providers have different security controls. CAA records are just another layer of defense in depth.
It's just, like many security features, a belt-and-suspenders approach. It doesn't protect against somebody maliciously getting access to my DNS API key (since they can just change the CAA and do a DNS-based auth against whatever CA), no, but it protects against two big things:
- A bug in the validation of some CA that I don't even use.
- For a bigger organization, some group doing "shadow IT" getting their own cert where the main IT group wants to be aware of all the organization's certificates (and more importantly where the private keys are). (See, for instance, what Facebook learned in the early days of certificate transparency, where if CAA had been implemented the certificates couldn't be issued at all.)
Mainly, it means that my attack surface is limited to the CAs I use, rather the weakest link of all browser-trusted CAs everywhere. It's not perfect, no, but it's something.
Also in theory one day they'll add more parameters to it, so that I can limit the usage to just DNS-01 authentication signed with some specific account key, and even if someone gets access to put a file on my web server (or does a broad-spectrum BGP hack good enough to trick a CA) they still couldn't get a certificate issued. Again not protecting against everything, but limiting attack surfaces to "just" securing DNS.
I suspect that the reason people see CAA errors is just that CAA is the first DNS record checked, and if the issue is a buggy authoritative DNS server or misconfigured DNSSEC or whatnot, that if CAA wasn't checked you'd just see the error when trying to resolve the TXT or AAAA/A record for the challenge. Maybe I'm wrong on the ordering, though?
I just wonder if it's a paper layer that serves more for efficiency for the CA.
I strongly suspect that you are correct here, Peter.
There are more ways to verify domain ownership than what Let's Encrypt uses. Most of them do work through some kind of DNS thing, but a lot of the possible verification methods rely on domain registry information for example. That's a different level of the DNS than just a hacked DNS zone.
Why would such a CA be trusted? Accidents happen, but testing should be thorough in this area.
That's certainly a possibility. I feel like this is an internal security/delegation problem though.
I would hope their authentication procedures would at least be strong enough to prove control of the domain name though.
I think that checking CAA is actually a bunch of headaches for the CAs, they just go through with it because (1) people want it (at least the people running the trust stores), and (2) it helps protect them somewhat from a malicious actor getting certificates that they aren't supposed to, even if the domain validation is correct. Certainly the details of getting it all right caused a big headache for Let's Encrypt and is a source of further compliance issues for other CAs too. It may not be great, but there are downsides to any CA with an issue possibly causing problems for all domains, not just those of their customers.
Because bugs happen. Look at Mozilla's current CA incident list. Each incident is a big problem, though rarely it's about validating a domain incorrectly (though sometimes it is!). But CAA lets the scope of the problem be just slightly smaller, and helps me protect my domain against the bugs of CAs that I don't use.
Sure it is. But it's convenient if one (as an IT administrator) can just put something in DNS to only use the official contracted or preferred CA, and not worry about what developers have managed to use HTTP-01 authentications for that the administrator don't know about. (Hopefully the administrator doing so has standardized a process to make it really easy for the developers/marketing/etc. to be able to get a real certificate without jumping through a lot of hoops, too.) I could imagine other advantages too, like checking the CAA for my domain (and even my subdomains) might be easier to automate in a self-security-scan, versus auditing that all my servers only use CAs I'm expecting.
I suppose one could consider the CAA record to be a "chainlink selector" since it reduces the burden of issuance restriction for the unspecified CAs by squarely placing the burden of issuance restriction on the specified CAs.
A CAA record is also very handy if you are an organization that has sub-groups that are allowed to manage their own namespaces.
For example, as a senior official in the organization, I can define a CAA policy for
example.com and then delegate
bar.example.com to different internal groups. The groups can manage their own namespaces, but the CAA record helps lock down their options to what I allow.
This type of selective authorization hits into what petercooperjr was stating. Totally valid though. I was originally inquiring from a global level. I suppose that proactive filtering of authorization certainly has its place. I distinguish aspects that overlap with domain name validation where an "accepted challenge-type" parameter would fall into the "security preference" category (due to being optional) and an "accepted CA" parameter would fall into the "security supplement" category (due to overlapping with standard domain name control authentication measures).
One thing to watch out for: the direction/method that the RFC specifies for traversing DNS is kind of counterintuitive. It’s important to read the RFC carefully when relying on DNS delegation for control.
For some reason I had the same perception, but it seems to be incorrect.
The result of the challenge has always taken precedence over the result of the CAA check.
Why on earth would it be worth doing anything if the CAA record expressly prohibits issuance!?
Just seems to me like squandering the most obvious opportunity for efficiency.
Any idea why this route was taken?
Yes: the ACME challenge is one query. The CAA check is potentially a series of queries all the way up the hierarchy.
Ah. Efficiency via parallel processing then? I would presume that the predicted path is one of the CAA record allowing issuance.