CAA, or Certificate Authority Authorization, provides a way to designate which CAs are allowed to create a Certificate for specific domains. This is done accomplished by publishing new caa
DNS records, with three directives: issue
issuewild
iodef
. For example:
$ dig craigslist.org caa
craigslist.org. 300 IN CAA 0 issue "digicert.com"
craigslist.org. 300 IN CAA 0 iodef "mailto:security@craigslist.org"
-^-
The 0
value in the record indicates the Flags for the record. At the moment, only two values are defined:
0
- Understanding this CAA record is optional
128
- Understanding this CAA record is critical
RFC 6844 specifies this regarding the Critical flag:
Flags: One octet containing the following fields: Bit 0, Issuer Critical Flag: If the value is set to '1', the critical flag is asserted and the property MUST be understood if the CAA record is to be correctly processed by a certificate issuer. A Certification Authority MUST NOT issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property tag that for which the issuer critical flag is set.
And earlier provides this as an example:
The critical flag is intended to permit future versions CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated domains. In the following example, the property 'tbs' is flagged as critical. Neither the example.net CA nor any other issuer is authorized to issue under either policy unless the processing rules for the 'tbs' property tag are understood. $ORIGIN example.com . CAA 0 issue "ca.example.net; policy=ev" . CAA 128 tbs "Unknown"
In all my browsing around, I've only see the flag set to 0
... with one exception:
$ dig stackoverflow.com caa
stackoverflow.com. 300 IN CAA 0 issue "digicert.com"
stackoverflow.com. 300 IN CAA 0 issue "letsencrypt.org"
stackoverflow.com. 300 IN CAA 0 issuewild "digitcert.com"
stackoverflow.com. 300 IN CAA 0 issuewild "letsencrypt.org"
stackoverflow.com. 300 IN CAA 128 iodef "mailto:sysadmin-team@stackoverflow.com"
-^^^-
The iodef
directive has a flag of 128
.
Presumably, what this means is if a CA (not specified in the issue
or issuewild
directives) is asked to create a certificate for "stackoverflow.com" and does not understand the iodef
record, they MUST NOT create the certificate.
But if they do not understand iodef
, they likely do not understand issue
and issuewild
(as all 3 are specified in the original CAA RFC. Which means they are likely to just issue the certificate.
If they DO understand the CAA RFC, then they understand all three directives, and would send the violation e-mail either way.
If Stackoverflow had set all of their CAA records to 128
, I wouldn't have thought much of it. But the fact that only the iodef
record has the critical flag turned on confused me. What benefit is there to turning on the critical flag on just the iodef
record, but not issue
or issuewild
?
To avoid this being speculative, I just want to clarify my question is not "Why did Stackoverflow choose to this". Instead, it is a generic "Why would anyone choose to do this, i.e., what is the purpose of this"
Late answer, but still relevant. The current CAA RFC is RFC 8659, which has some additional information on the Critical Flag.
It does still not answer the question why someone would choose for this exact setup, so the critical flag to 0 for issue
and issuewild
directives, but 128 for the iodef
record. I basically see two situations where such configuration makes sense:
Like every service provider, CA's might implement CAA incorrectly. It is unlikely, but it happens. issue
and issuewild
are clearly the core of CAA, not supporting these tags is equal to not supporting CAA at all. iodef
, on the other hand, is an addition: not only do we block CAA requests when the CA is not allowlisted, but we also alert the user about the fact that we got blocked. Maybe, some CA that is in the process of implementing CAA, implements the core tags first, and adds iodef
later on. This is of course speculation. The outcome of setting 128 to all CAA records would do not change the outcome, but StackOverflow considers the support of the iodef
directive, thus the sending of alert e-mails, critical. Ironically, not supporting the iodef
record would of course lead to no alert e-mail be sent, and like you said, not supporting CAA at all would lead to the issuing of the certificate. That is why we must hope CAA support will be a strict requirement for being a CA.
A future CAA version might overwrite, change or replace the iodef
directive because they have decided on a new alert method that has become more popular than e-mail. The current setting marks the current iodef
as critical, and thus indicates that the record should be successfully parsed, or the CA should deny. If the specs change in regards to iodef
should be handled, the CA has to deny the certificate if it cannot handle this old iodef
tag.
That being said, it is still unlikely this will really make a huge difference. But that accounts for the CAA record as a whole, it is really a security-in-depth measure that is more likely to alert on misconfiguration than have a large impact on security.
External links referenced by this document: