[cabfpub] Ballot 187 - Make CAA Checking Mandatory

Jacob Hoffman-Andrews jsha at letsencrypt.org
Mon Feb 27 02:14:55 UTC 2017

I agree that we want CDNs and hosting providers to be able to easily set
default CAA policies for hostnames that are CNAMEd to them. They know which
CAs they actually use, and usually terminate TLS, so they can accurately
set policy for a large number of domains at once with very little
disruption. It's also useful for domain owners to be able to punch out
exceptions to a CAA record specified by their CDN for many reasons[1].
CAA's left-to-right evaluation order gives both of these properties.

However, I think the recurse-into-alias-before-resuming ("authorial
intent") version of CAA is not needed to accomplish those goals. For
instance, in Peter's example:

> www.paypal.com. 453 IN CNAME www.paypal.com.akadns.net.
> www.paypal.com.akadns.net. 30 IN CNAME ppdirect.paypal.com.akadns.net.
> ppdirect.paypal.com.akadns.net. 180 IN CNAME wlb.paypal.com.akadns.net.
> wlb.paypal.com.akadns.net. 30 IN CNAME www.paypal.com.edgekey.net.
> www.paypal.com.edgekey.net. 0 IN CNAME e3694.a.akamaiedge.net.
> e3694.a.akamaiedge.net. 20 IN A

Akamai could add this record to set a CAA policy:

e3694.a.akamaiedge.net CAA 0 issue "symantec.com"

I don't see an additional need to let Akamai set this policy at the
akamaiedge.net level instead.

I also see "authorial intent" CAA as a little trickier to implement
correctly than "erratum 4515
<https://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4515>" CAA.
Normally, a recursive resolver is responsible for chasing CNAMEs and
detecting loops. Application code doesn't need to care about CNAMEs, only
the final resource record. Implementing "authorial intent" CAA requires
application code to specially handle CNAMEs and break loops. I think this
is likely to introduce more bugs and inconsistent implementations.

So, my inclination is to follow Phillip's option (2): Turn erratum 4515
into a new RFC, and follow that. But I'm willing to be convinced otherwise.
Relatedly: Phillip, is there an appropriate IETF mailing list to which we
could take the conversation? It would be good to get broader technical
input, but this is a restricted-posting mailing list.

[1] domain owners may need certificates for non-HTTPS purposes; they may
CNAME their base domain to a CDN, but have a wide variety of subdomains
that are not hosted by that CDN; they may use a TCP-only CDN that doesn't
terminate TLS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170226/31985b03/attachment-0003.html>

More information about the Public mailing list