About this Study

Shaken by severe compromises, the Web’s Public Key Infrastructure has seen the addition of several security mechanisms over recent years. One such mechanism is the Certification Authority Authorization (CAA) DNS record, that gives domain name holders control over which Certification Authorities (CAs) may issue certificates for their domain. First defined in RFC 6844, adoption by the CA/B forum mandates that CAs validate CAA records as of September 8, 2017.
The success of CAA hinges on the behavior of three actors: CAs, domain name holders, and DNS operators. We empirically study their behavior, and observe that CAs exhibit patchy adherence in issuance experiments, domain name holders configure CAA records in encouraging but error-prone ways, and only six of the 31 largest DNS operators enable customers to add CAA records. Furthermore, using historic CAA data, we uncover anomalies for already-issued certificates. We disseminated our results in the community. This has already led to specific improvements at several CAs and revocation of mis-issued certificates. Furthermore, in this work, we suggest ways to improve the security impact of CAA. To foster further improvements and to practice reproducible research, we share raw data and analysis tools.

Paper Download

Our paper has been published in the April 2018 issue of ACM SIGCOMM CCR: Link.
You can download the initial submission, camera-ready version, BibTex entry, and raw data.
Initial submission was Dec. 1st, 2017, acceptance Mar. 21st, 2018, and publication May 1st, 2018.

CAA Adoption

Please note: Due to personnel capacity constraints, we have stopped publishing results for this study in January 2019.
Note: We have removed some invalid data points, for example in early December and in early February. The removed data points were typically caused by network problems, sometimes due to explosive growth.

We perform regular scans of >200M domains for CAA support and show their CAA adoption above.
Anomalies: The peak in "TUM-DETAIL with CAA or CNAME2CAA" in early November stems from a hoster enabling CAA on its base domain, to which about 15k customer domains point.
The jump in early February also stems from 2 hosters enabling CAA on its base domain, with 60k and 57k base domains pointing to it via CNAME.
Starting February 9, 2018, we are also removing domain names of the pattern google[a-f0-9]{16}.sld.publicsuffix from our scan. These are used to assert domain DNS control by google by placing such as CNAME that points to google.com (see here). As google.com deploys CAA, these base domains were counted as deploying CAA, which they are effectively not.
The fluctuations in October 2018 stem from on/off rate-limiting issues at nazwa.pl, which hosts about 200k CAA-enabled base domains.

CAA Flag and Tag Use

-

These figures show the use of CAA tags by base domains.

CAA name server inconsistencies

# of domains that return inconsistent CAA configurations across their authoritative name servers. The peak in October 2017 is discussed in our paper. The peak in October 2018 stems from a surge of domains at e-i.net and 36dns.net having inconsistent existence of issue/issuewild across nameservers.

Issuance Experiment

The results from our issuance experiment can be found under https://github.com/quirins/caa-test.

End-to-End Audit

Issuance Anomalies uncovered in our end-to-end audit can be found on Mozilla NSS Bugzilla and the MDSP mailing list
We link some specific bugs here. These are not meant to highlight mis-issuances, but give the reader further background on typically anomalies found and how investigation was conducted. Some bugs revealed to be False Positives (FP), these are marked.

Contact

caa [AT] list.net.in.tum.de

Partner