[cabfpub] Ballot 187 - Make CAA Checking Mandatory

[Ryan Sleevi]

Resharing on behalf of Patrick Donahue <pat at cloudflare.com>, at Cloudflare.

On Sun, Feb 26, 2017 at 6:14 PM, Jacob Hoffman-Andrews via Public <
public at cabforum.org> wrote:

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

For the most part. As both an authoritative DNS provider and Applicant of
certificates on behalf of our customers, we have to be careful here in i)
setting safe defaults and ii) helping users that do explicitly want CAA to
create records that don't lock out their other legitimate issuance. As you
point out in your footnote, they may need to acquire certificates for
non-HTTPS purposes (or for HTTPS that doesn't route through their CDN for
whatever reason); this is especially true in large and/or decentralized
organizations.

While we'd love to adopt CAA en masse, we can't simply add default CAA
records. Instead, what we plan to do is design our DNS interface to allow
users to easily specify one or more of the following for their domain
(and/or subdomain, etc.):

   1. Allow issuance from Cloudflare's current Universal SSL and Dedicated
   SSL partners (i.e., several CAs on this mailing list)
   2. Allow issuance from CAs that issued the certificates they've uploaded
   to us (or will upload in the future)
      1. As discussed on Twitter with Gerv and Jacob, there's no easy or
      unambiguous way to automate this lookup. Relatedly, I am a fan of Ryan's
      suggestion on making the CPS be machine-readable so these CAA
values can be
      extracted by code rather than humans.
   3. Allow issuance based on the exact CAA record that I manually set.

In options #1 and #2 above, we intend to update CAA records dynamically as
this list of user-permitted CAs evolves. We expect option #3 will be used
by more "advanced" users (and likely will roll out first to accommodate the
requests we're fielding from early adopters).

And while I agree with all of Ryan's points related to this specific
situation being a business and not technical concern, option #3 can be used
to accommodate Matt's use case of preventing automated issuance during
onboarding (or thereafter). Expanding on this a bit: because we prompt for
existing (and new) DNS records prior to providing authoritative nameservers
to be set at the registrar, users wishing to prevent automated issuance
could set CAA at the outset—and the CAs we automatically request issuance
from would see this record/hopefully follow the BRs.


> 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:
>
> ;; ANSWER SECTION:
>> 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 23.13.156.181
>
>
> 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.
>
>
Agreed. And I don't really see what we're trying to accomplish here. How a
domain resolves—whether directly to an A/AAA record or through a series of
CNAMEs—is an implementation detail for that domain owner, not (in my
opinion) relevant to CAA.

In the PayPal example above, a certificate is being requested with a SAN of
"www.paypal.com". Why would a CA need to check anything other than CAA
records set on the nameservers authoritative for "paypal.com" and "
www.paypal.com"? Same answer applies for Peter's original question: "If a
CA gets a certificate request that includes dNSName:beta.shop.example.com,
what DNS queries must it make to check for CAA records?"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170227/0af645b3/attachment.html>