Certificate Authority Authorization Records

| Comments (2) | COMSEC DNS
As I said earlier, DANE faces serious deployment hurdles, even in certificate lock mode: it works best when the records are signed with DNSSEC, and even if you deploy it without DNSSEC, which is tricky, it only provides protection to clients which have been upgraded, which is going to take a while. Phillip Hallam-Baker, Rob Stradling, and Ben Laurie have proposed a mechanism called Certificate Authority Authorization (CAA), which, while more of a hack, looks rather easier to deploy.

With CAA, as with DANE, a domain can publish a record in the DNS that says says "only the following CAs should issue certificates for me." However, unlike DANE, the record isn't addressed to clients but rather to CAs. The idea here is before issuing a certicate to a domain a CA checks for the CAA record; if there's a record and the issuing CA isn't on it, it doesn't issue the certificate. This mechanism has the advantage that there are only a relatively small number of root CAs and they have a relationship with the browser vendors, so the browser vendors could at least in theory insist that the CAs honor it, thus providing some protection to everyone almost immediately. Moreover, it's easier to recover from screwups: if you misconfigure your CAA record, all that happens is a CA can't issue you a new cert till you reconfigure your DNS, as opposed to your site suddenly becoming unreachable.

Obviously, CAA is inferior to DANE an end-to-end security perspective, as it relies on all the CAs behaving correctly. However, since the primary risk here is probably not intentional CA malfeasance but rather the comparatively weak authentication procedures many CAs use. However, if a CA is able to determine that under no circumstances should they be issuing a certificate for a domain, then the weakness of those authentication measures becomes somewhat less important. It's not perfect but it seems like a potentially worthwhile risk containment strategy, especially as it allows you to select a certificate authority whose security measures you trust, rather than having to rely on the security of the weakest CA on the browser root list.

2 Comments

CAA sounds like a step in the right direction. However, I'd like to point out that "intentional CA malfeasance" is a significant risk if your adversary is a nation-state.

I am not quite sure why you regard CAA as a hack. One of my problems with the DANE WG has been the lack of rigor or generality in the approach.

They are currently discussing the use case where the administrator wants to use a self-signed X.509v3 certificate as an EE cert. That may be a feature people want to see in the final spec but it sure isn't what I would consider to be a 'use case'. Why not cut to the chase and call the code library a use case?


CAA records may be directed to either an issuer or a relying party application or both. So if you have decided that all your certs at example.com are to come from one CA, you can provide that information in a way that is fully enforceable in clients.

What CAA does not have is a means of specifying client restrictions that are specific to particular protocols. That is not because we did not think that would be useful, its because we wanted to get the issuer restrictions out first.


There is in fact a principled means of extending CAA down to the protocol level and even to the host level that is fully compatible with the peculiarities of the DNS system.

Say we want to specify a key for the SIP protocol. We can do that by putting a property in the CAA record to say 'more detail here for SIP'. For example:

example.com CAA 0 ESRV "_sip._tcp"
_sip._tcp._example.com ESRV 3 PATH MDIGA1UEJQYJYIZIAWUDBAIBBCAXzJgPaoT7Fe
XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA==

This makes a declaration that is specific to the sip protocol. Now obviously there is a limit to how many times you can do special cases and at some point the ESRV record is going to have to say 'lookup ESRV for every protocol'.

Why do it this way? Well one is some technical stuff to do with the way that prefixes interact with CNAMES and wildcards in the DNS. Basically a record that is used with a prefix must always be prefixed and the prefix must only be applied to canonical names. Otherwise bad things happen. That is why prefixing TXT records is a bad idea.

The other reason for this approach is that it allows for a mechanism that is compatible with using extended discovery mechanisms such as SRV and URI.

The full details of how I think this should be done are to be found in:

http://tools.ietf.org/html/draft-hallambaker-esrv-01

Compared to the current Hoffman draft in DANE, my proposal has identical performance for the use cases of interest, is fully compatible with DNS use of aliases and wildcards and is compatible with the use of extended discovery mechanisms. It is also an extensible framework that is also designed to support requirements such as signaling strict security and availability of opportunistic encryption. The Hoffman draft on the other hand is only trying to meet a small set of requirements, depends on the well known ports discovery mechanism that is going to run out of ports fairly soon and is only designed to support TLS.


The only way in which CAA is a hack is that is can be deployed very quickly. The only thing that stood in the way of deployment was the definition of the CAA RR record code point which has now happend (257).

Leave a comment