Re: [Spasm] CAA erratum 4515

[Ryan Sleevi <[e-mail]>]

On Fri, Mar 10, 2017 at 3:22 PM, Jacob Hoffman-Andrews <[e-mail]> wrote:

> On 03/10/2017 11:43 AM, Ryan Sleevi wrote:
>
> Agreed. To aid understanding, could you re-explain in your own words why
> your examples show the CDN setting CAA records in the Self-managed case? I
> copied that into my own examples for consistency, by I had to guess at the
> reasons.
>

Which example? Are you talking about "example.net           CAA 0 issue "
evil-ca.example.org" ?

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" 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") and co-hosts one or more customer domains ("
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.



> 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" and "
example.net" as two independent organizations with their own policies, for
which they wish to express as efficiently and simply as possible.


> The "reduced examples" are simply the regular examples with those common
> entries removed.
>

Right, but I think the understanding of these policies - and that these
policies are in play - are key to making progress and discussion :) The
fact that it involves remembering whether or not a policy is set
(implicitly) is exactly why I tried to explicitly indicate in all of the
examples what I mentioned above - different domains have different policies.


> My goal here was to give trampoline and non-trampoline examples their own
> distinct names, so we can compare them side-by-side in each world. The
> conclusion I come to is that there is not a significant difference.
>

Right, and the conclusion I've come to is that the level of operational
burden shifts, subtlely, and while I think both offer a degree of
flexibility to allow the use cases, the burden for how that configuration
is made and managed is sufficient enough to prefer one over the other -
this is the subjective portion that I was leading to, by first making sure
we had a consistent objective measure.


> Maybe we can come at this from a different angle: I think you are saying
> that in the non-tree-climbing world, CDNs would need to use the trampoline
> to make it possible (or convenient?) to express a certain CAA policy.
>

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


- Are you arguing that trampolines make a certain policy possible, or just
> more convenient?
>
- In the non-tree-climbing world, are you arguing that trampolines are
> necessary for Self-managed, Externally-managed, or both?
>

I think both of these questions misunderstands what I was trying to
present. I think you're seeing it as a discussion about whether or not
trampolines are required - I was attempting to discuss how the
configuration looks when trampolines are used, and when they're not, and
compare the operational difficulties that arise in supporting both
self-managed and externally-managed issuance policies in both tree-walking
and non-tree-walking scenarios.