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.
The DNS standard is very clear that the only correct thing for a server that's authoritative for somename.example to do when asked somename.example FOOZLE? and it has no idea what FOOZLE is but somename.example exists will be to say there are zero answers OK.
However, despite that it appears several semi-popular commercial DNS server products exist which get this (and other things) wrong. They answer A? and these days often AAAA? correctly but they get a lot more wrong, likely including problems when asked CAA? still today's web browsers mostly ask A? and AAAA? so just getting those correct is enough to seem like your server "works" for a not very inquisitive customer and once the customer has purchased the product who cares if it works right?
Because DNS is so essential it is critical that it's implemented correctly, down the road from here for example HTTP/3 deployment is expecting to depend heavily on HTTPS/ SVCB records in DNS, obviously a server that can't answer CAA? correctly is not going to get that right either. But in a web browser it's OK to just race and measure - your browser may conclude your network is too broken to bother trying HTTP/3 so you get the HTTP/2 or even HTTP/1.1 protocol and things are a little slower but it works. Let's Encrypt is forbidden from just assuming your server is broken and passing along, your server must know how to answer CAA? and unfortunately a minority still can't get that right in 2020 even though a compliant 1990s DNS server would have correctly reported "zero answers OK".
Sorry, a bit off topic.
I have to point out that I like the idea of the security feature what the CAA record is providing. The owner of the domain specifies which CA is allowed to issue certificate for the given domain. I love it.
After all this preamble, I must tell my opinion that the DNS lookup traversal for the CAA record is a very-very bad idea. I consider the RFC being broken.
I would like to have a different CAA standard specification without DNS traversal. By that (incompatible for sure) specification, the CA just simply looks up the CAA record of the actual domain name for which the certificate is to be issued, to know its own permission for issuing the certificate.
That would certainly make things simpler on the CA side, but then I as a domain owner need to ensure that every time I add a subdomain that I add a CAA record for it. It gets even trickier if I'm using DNS-01 challenges to get certificates for accessible-only-on-my-network devices, since then rather than just automating the DNS challenge as needed I need to leave a CAA record out there indefinitely for each one. All solvable problems, sure, but it's a whole lot easier to just put a CAA record at my main domain name level for my entire organization and be done with it.
But checking CAA all the way up to the TLD level, so that a misconfiguration on
.com would stop all certificate issuance under it for anyone who hadn't established their own CAA record? That does seem rather… weird.
There's probably no perfect answer, and the existing standard has all the advantages of being done by a committee of interested parties and all the disadvantages of being done by a committee.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.