Re: [Spasm] CAA erratum 4515

[Jacob Hoffman-Andrews <[e-mail]>]

On 03/10/2017 01:18 PM, Ryan Sleevi wrote:
> Which example? Are you talking about "example.net <http://example.net>
>           CAA 0 issue "evil-ca.example.org <http://evil-ca.example.org>" ?
Yep.
>
> That's because the site operator should be able to set their own
> policy for their own domains. This is why I dislike the "CDN" example,
> because it comes with it the implication that somehow "example.net
> <http://example.net>" is reserved only for CDN customers, whereas I
> think the marketing site example, a more common scenario, has the
> marketing company providing services at their own domain (e.g.
> "www.example.net <http://www.example.net>") and co-hosts one or more
> customer domains ("terrier.example.net <http://terrier.example.net>").
> The point here is that it's rare for a single domain tree to be
> limited to a single (self-hosted/externally-hosted) policy.
Great, looks like we're in agreement here. Personally I was taking it
for granted that CDNs (or hosting providers) often have a mix of
subdomains serving both their own sites and their customer sites, so
this didn't feel confusing, but I appreciate you clarifying it.
>
>  
>
>>     These configurations are a little confusing, since you don't
>>     define goals. I assume the goals in this example are:
>>      (a) Every domain and subdomain in the example is covered by a
>>     CAA policy, and
>     Can you confirm whether this is an implicit goal in your examples?
>
>
> I'm not sure I would suggest it like that, but again, I think we may
> simply be agreeing but talking past eachother :) I see "example.com
> <http://example.com>" and "example.net <http://example.net>" as two
> independent organizations with their own policies, for which they wish
> to express as efficiently and simply as possible.
Yep, that makes sense. One thing that might help is to detail that there
are actually three policies in play, that we've tended to squash into two:

1. Policy set by user-facing domain owner for their own hostnames.
2. Blanket policy set by CDN for hostnames they operate on their
customers' behalf.
3. Policy set by CDN for their own hostnames, which share the same base
domain as the CNAME targets used in (2).

The goal is that these can be set as three independent policies, without
unintended interactions.

Also, one thing I want to clarify: To what extent are you trying to
incentivize (2) and make it easy to do? I've been assuming that's a core
goal for you, but I may be misunderstanding that.
> If domain operators wish to operate with their own policy, but support
> customers with another policy, the trampoline is necessary or the
> customer has an additional configuration step.
This depends. Are the CDNs trying to support unique policies on a
per-customer basis, or a blanket policy as in (2) above? If it's a
blanket policy, no trampoline is needed. The CDN does need to have a
CNAME target that is not a base domain, but that target doesn't need to
be unique per-customer: i.e., not a trampoline.
> If domain operators wish to operate with their own policy, and support
> customers with the same policy (on the domains the domain operator
> operates), while allowing their customers to operate with their own
> policy on the customer domains, the trampoline is necessary.
I don't think this case is significantly different than the above. One
policy gets set on the CDN's base domain, while the other policy gets
set on the CNAME target. If those policies happen to be the same, that's
fine.