Re: [Spasm] CAA erratum 4515

[Patrick Donahue <[e-mail]>]

I've previously shared my thoughts on this topic here:
https://cabforum.org/pipermail/public/2017-February/009850.html.

With respect to Jacob's initial tee-up:

www.staffie.dog.        CNAME staffie.terrier.dog.
staffie.terrier.dog.    A 192.0.2.1
terrier.dog.            CAA 0 issue "happy-hacker-fake-ca.net"


Should issuance for www.staffie.dog require a CAA query for terrier.dog? Or
> should it only require CAA queries for www.staffie.dog and
> staffie.terrier.dog?


I'm a bit confused here as I would say "no" to the first question and I
would say that staffie.terrier.dog is irrelevant in the second part of the
question (but a CA may need to check staffie.dog if nothing set at
www.staffie.dog).

Can someone explain why the issuance check would need to do anything other
than:

   1. Look up CAA record for www.staffie.dog.
   1. If present
         1. Pass/fail based on contents.
      2. Else (i.e., if not present)
         1. Look up CAA record for staffie.dog.
            1. If present, pass/fail based on contents.
            2. If not present, pass.


If you control where www.staffie.dog points, you can do anything you want
with it content-wise. Why are we proposing tying certificate issuance to
the underlying (hosting provider/CDN/whatever) implementation?

If CAs are required to look up intermediate hostnames that are part of the
CNAME chain, we—as a large managed DNS provider—will be far less likely to
encourage CAA adoption and build tools to facilitate it. Otherwise we risk
not being able to issue certificates for our non-authoritative DNS
customers and, as a result, provide a poorer user experience while
simultaneously increasing our support costs.

For example, I've had calls the past couple of weeks with SaaS customers
that provide their app to hundreds of thousands of their end-customers on a
"vanity" hostname, e.g., app.saas-customer.com (rather than a non-"vanity"
hostname such as saas-customer.cloudflare-customer.com)

During onboarding, our customer instructs their end-customer to CNAME the
subdomain "app" (or whatever) to customers.cloudflare-customer.com, which
is reverse proxied through our network and thus facilitates doing HTTP DCV
at /.well-known/pki. Why should cloudflare-customer.com's CA preferences
for their own domain affect what certificates their end-customer can
receive?

On Thu, Mar 9, 2017 at 1:07 PM, Jacob Hoffman-Andrews <[e-mail]> wrote:

> On 03/09/2017 12:35 PM, Ryan Sleevi wrote:
>
> I want to be careful here restricting it to the notion of "CDNs",
>
> I'm using CDN as a shorthand for "hosting provider or CDN." In the Twitter
> example, the other stakeholders are the marketing department and the
> contractor who develops the web content, neither of whom have CNAMEs in the
> mix. Is there another entity type I'm missing?
>
> *Hole punching and the includeSubDomains problem*
>>
> As you noted elsewhere, to effectively get this scenario, the operator of
> superbowl2017.twitter.com (which we'll call example.com) would need to
> set up the destination of CNAME in such a way as to be able to
> appropriately express the per-customer policy (if Twitter handles
> certificate provisioning) - that is, superbowl2017.twitter.example.com -
>  or, as you noted, would need to effectively set the CAA record as a
> 'wildcard' / for every customer.
>
> I don't understand why example.com would need to set a per-customer
> policy. If terrier.dog handles certificates for their customers, they would
> do so with a limited set of CAs, and could set that as policy on their
> domain names. If a specified customer like www.staffie.dog needs a
> different policy, they can set it on their own hostname:
>
> www.staffie.dog.        CAA 0 issue "sad-hacker-totally-real-ca.net"
>
>
> I don't think trampolining is necessary to make this work.
>
> If terrier.dog doesn't handle certificates, e.g., if they expect customers
> to bring their own cert from any CA, then they can't reasonably set a
> blanket policy for all their customers. In that situation, I think it would
> similarly be up to the customer to set a CAA policy on their own hostname
> if they wanted one, since the customer is the one with the CA relationship.
>
>


-- 
Patrick R. Donahue
[e-mail]

PGP Fingerprint: 2E8D 5A38 682E EC00 C0F3  E7F2 D9BE 68D2 ABF3 6B24