Things are heating up at the CA/Browser Forum with exciting proposals surrounding inclusion of the Wi-Fi Alliance (WFA) as a subjectAltName otherName, new validation methods, and debates over how the CAB Forum will continue operating.

One of these new proposals is the recently passed Mozilla ballot that will require all Certificate Authorities (CAs) to check and process a domain name’s DNS Certification Authority Authorization (CAA) resource record prior to issuing a digital certificate.

Although there are several potential concerns with mandatory CAA checking, the benefits associated with CAA are sufficient such that DigiCert supports the project. The potential issues cited tend to have minimal impact on performance and are largely theoretical issues. CAA is a policy control, meaning a CAA failure isn’t a requirement without a work around if things go awry. Unlike some of the technical controls, even the most malicious use of a CAA record would not brick a server.

CAA Background

RFC 6844 created CAA records as a method for domain owners to specify a policy on which certificate authorities are authorized to issue certificates for the associated domain. The basic concept is that immediately prior to issuance, the CA will check the CAA record and determine whether policy permits creation of the certificate.

Issuance is permitted if either a CAA record doesn’t exist for the domain or the CAA record lists a string specified by the CA as authorizing the CA to issue the certificate. Using CAA records, the domain owner can control policy at a more granular level, including specifying which CA can issue Wildcard certificates and how to report issues.

Note: CAA record checking is an additional requirement that occurs after the CA completes the normal domain verification process required by the CA/Browser Forum’s baseline requirements under Section 3.2.2.

The push for CAA record checking was driven by the increasing number of entities embedding roots in the browser, with over 60 entities currently operating embedded roots. Most of these CAs permit customers to issue a publicly trusted certificate regardless of the server’s location or internal certificate policies.

Prior to CAA an attacker could request each CA to issue a certificate. If even one of those validation attempts passed (regardless of whether  this was a mistake on the server operator’s side or a lapse in the CA’s validation practices), the attacker could get the certificate issued. On the contrary, with all CAs respecting CAA records, the attack vector is theoretically limited to those CAs listed in the relevant CAA record.

After CAA record checking is adopted as a requirement—and assuming the CA logs their certificates to CT logs—the CA issuance process looks like the following:

Although CAA record checking appears straightforward, there are complexities in the process. For example, a CAA record is permitted at any label within a fully qualified domain name (FQDN), requiring the CA to check each label within the FQDN until a CAA record is found. The first record encountered when following the labels controls policy, meaning CAA policy can be applied on granular level by the DNS operator. For IoT devices the FQDN often looks similar to the following:

[randomID].[customerID].secure.IoT.domain.com

In this case a CA would start by checking [randomID]. This usually lacks a DNS listing, moving the CAA check to customerID, followed by secure, then IoT, then domain. If no records are found, the CA issues the certificate.

If a CAA record is found, the first record encountered will dictate authorization. Another complexity is that the CA must check each record twice if a response from the DNS is not received. For domain names with large labels of non-resolvable labels, this results in wasted cycles.

Although CAA record checking provides greater control over certificate issuance to domain owners, there are several benefits and concerns worth considering when assessing this proposal.

Benefits of CAA

The obvious benefit of the ballot is that CAA record checking will become a uniformly deployed method of communicating policy to CAs. Effective September 2017, all CAs will be required to check and abide by CAA records.

Prior to this requirement, CAs implemented CAA checking on an opt-in basis, which meant that CAA lacked any real protection for server operators. With all CAs checking CAA records, the server operator can limit their universe of known certificates to a handful (or one) CA.

Futher, enterprises can utilize CAA to force their organization into a uniform issuance policy that’s enforced by the CAs. For example, if Company Y acquires Company Z, Company Y can add a CAA record to Company Z’s DNS to require the acquired company to move to their certificate policies. This is a significant benefit for larger organizations where business divisions and new acquisitions may not be aware of the parent’s organizational PKI structure or relationships. Although a business division could get around the policy by intentionally creating a CAA record at a higher label, CAA will help enterprises prevent policy violations caused through ignorance.

Another positive is the speed at which CAA record checking occurs. CAA record checking takes about 7ms per record, which isn’t a heavy tax on most systems.  Customers with the most complicated FQDNs will likely not see longer issuance times, assuming their CAA records are correctly configured.

Concerns Involving CAA

Mandatory CAA record checking presents valid concerns and some potentially undesirable outcomes.  The largest of these is the lack of a clearly defined policy for how CAA checking works with CNAME records.

Section 4 of the RFC specifies that a record check should trace through aliases but doesn’t specify how this tracing occurs. For example, if a record is created for mail.example.com CNAME secure.example.net, where mail.example.com has a CAA record of certificateAuthorityA and example.net has a CAA record of certificateAuthorityB, the specification is unclear on which CAA record should control.

A second issue is that software supporting CAA is scarce at both the DNS and CA level. At the end of 2016, most off-the-shelf CA software did not natively support CAA checking prior to issuance. Although DigiCert has its own CA software, many other CAs are at the mercy of their software provider for making necessary changes.

September 2017 is a short implementation deadline considering most CA software is designed to support private PKI implementations, a market where CAA is not required. CAA record-checking deployment may be problematic for small CAs lacking the resources to build their own automated tools.

On the DNS-side, DigiCert has encountered around three to six CAA records ever…and most of these records were created with our assistance. Recently, DNS providers have expanded support, and CAA record creation is possible in the latest version of BIND, NSD, Knot, and PowerDNS.

Despite CAA expansion, DigiCert still hasn’t encountered an increasing number of records. Whether the lack of records is caused by a lack of software support or a lack of perceived value, CAA records aren’t being used by enterprises. CAs will be spending a lot of time and energy setting up and checking records that don’t exist.

Another challenge is the difficulty of determining whether a CA is properly checking CAA records.  Unlike CT, which publicly discloses issued certificates, CAA is a point in time check by the CA.  A public record of the CA’s check is not available. Provided the CA doesn’t issue for high profile domains, a bad-acting (or ignorant) CA could ignore CAA records and not get caught.

Finally, the DNS operator may not be the individual ordering certificates and, with large multi-national enterprise, may not have clear communication on which CAs are used internally. This could unintentionally limit contract obligations already in place, halt ongoing projects, and prevent an organization from getting the certificates needed to conduct e-commerce – negatively affecting the bottom line.

CAA records ignore all previous relationships and communications between the organization ordering the certificate and CA, meaning a single DNS administrator could undermine months of negotiation. Even worse, a malicious or disgruntled DNS administrator could stall a company by setting a large DNS record TTL and entering garbage in the CAA record, effectively eliminating the company’s ability to obtain certificates from any CA until the TTL expires.

Where Do We Stand?

Though some valid concerns persist, DigiCert supported (and endorsed) the ballot for mandatory record checking. Most of the issue cited have minimal impact on performance, a company’s operation, and a CA’s ability to issue certificates.

When the CAA ballot was initially introduced, we were concerned about processing times and CPU usage. However, our tests showed that the average CAA record check was completed within 7 ms. Although many domains may have five or more labels, that still only adds a latency of 35 ms. Mozilla’s proposal further reduced processing power concerns by exempting technically constrained intermediates from performing the check and removing the requirement that CAs retry DNS failures more than once.

Our second  question involved the new authority granted DNS operators. Although permitting DNS operators to set policy is part of the CAA design, CAA records trumping legal agreements, previous arrangements, and potentially blocking all certificates seemed like a problematic practice. However, considering the low rate of CAA records, the requirement that the first encountered CAA record controls, and the difficulty to add CAA records, we decided the malicious attack was sufficiently mitigated.

For some, the CAA record checking might be slightly redundant to the authorization step involved in getting an Organization Validated (OV) certificate. During the OV process, a CA’s validation staff check that the certificate is authorized for issuance.  With CAA, this approval is added directly to the DNS.  Important identity information is provided as it is in an OV certificate, though not all browsers recognize OV certificates directly.

Browsers’ support for CAA is an important step in recognizing the need to identify the certificate holder and the certificate holder’s authority to obtain the certificate.  CAA checks are a nice technical way to add this authority check through the DNS.  We look forward to other creative ways to introduce more robust OV checks like CAA on other subject information fields. CAA is definitely shows that the identity of the certificate holder and certificate holder’s authorization are just as important as encryption.

Overall, we expect CAA will have a minimal impact on the security and complexity of the web. However,  we are happy for the incremental improvement, especially where the cost of this particular process is low. To add a CAA record containing DigiCert, add digicert.com as your provider. For example, “example.org CAA 1 issue ‘digicert.com’”.

We also invite domain operators to provide their input about how this works in actual deployment and how CAA can be improved. Please send your feedback to Jeremy.rowley@digicert.com and we will happily pass it along to the CAB Forum in the interest of continual improvement.