Information Security
tls dns caa
Updated Tue, 04 Oct 2022 12:44:57 GMT

What is the purpose of the critical flag being enabled (128) on a CAA IODEF record?


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"

Solution

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:

  1. 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.

  2. 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

External links referenced by this document:

References