Re: [Spasm] CAA erratum 4515

[Ryan Sleevi <[e-mail]>]

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

> I chose these advisedly. Example.{com,net,org} are actively harmful for
> reading comprehension, because their distinguishing parts are small and
> come at the end rather than the beginning. Since this is a conversation,
> not a normative document, I believe there's no requirement to use the
> reserved domains. Do you disagree?
>

Considering how many 'discussion' examples I've seen get implemented in
code as part of tests (often incorrectly), I try to err on the side of "Do
no harm". Especially with countless email and spam filters that are going
to start poking the domains to see if they should block the emails.


> Since we both care about terminology, I'm going to recommend we instead
> use the RFC 6844 terms I used in my previous email: tree climbing vs
> non-tree climbing. Recursive already has a technical meaning in RFC 1035
> which differs from this one.
>

Fair point


> 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
>  (b) Those CAA records are compatible with these policies:
>     (1) the owner of the user-facing domain will only buy certs from a
> certain CA
>     (2) the owner of the CDN domain will only buy certs from another,
> different CA.
>
> Is that accurate? I'll adopt the CA names "user-facing.ca." and "
> enterprise.ca", since both our example CA names implied goodness or
> badness, which is not relevant to the discussion.
>

I'm not sure user-facing and enterprise brings the level of clarity you
hoped for, because it also implies a degree of policy that is different
from the self-managed/externally managed case. But I think we're in
agreement that we're talking "Foo" and "Bar" and never the twain shall meet.


> I'm going to introduce one more assumption: the CDN issues certificates
> for their own internal subdomains, and wants a CAA policy for those. This
> is necessary to explain why the CDN sets any CAA records at all in the
> Self-managed case. And I think this is what's implied by your examples -
> right?
>

I think "internal subdomains" introduces an unnecessary degree of
ambiguity, especially with your example of "enterprise.ca". I'm not sure if
this is indicative that we're talking past each other or not.

Both organizations want to set their own CAA policy as appropriate. I think
that should be uncontroversial and without complication.


> I think it makes the most sense to start with two baseline configs:
> trampoline'd and non-trampoline'd, and from there define what *additional*
> CAA records are necessary in the various worlds of Self-managed vs
> Externally managed, and tree climbing vs non-.
>
> Trampoline'd config:
>
> www.staffie.dog.        CNAME staffie.terrier.dog.
> staffie.terrier.dog.    A 192.0.2.1
>
>
> Non-trampoline'd config (all customers CNAME to the same www subdomain):
>
> www.beagle.dog.        CNAME www.hound.dog.www.hound.dog.         A 192.0.2.2
>
>
> Self-managed, tree-climbing:
>
> www.staffie.dog.        CAA 0 issue "user-facing.ca"staffie.dog.            CAA 0 issue "user-facing.ca"www.beagle.dog.         CAA 0 issue "user-facing.ca"beagle.dog.             CAA 0 issue "user-facing.ca"
> terrier.dog.            CAA 0 issue "enterprise.ca"
> hound.dog.              CAA 0 issue "enterprise.ca"
>
> I personally find this structure much harder to follow, so I may have
missed things - if only because you're describing the permutations for
trampoline and non-trampoline in the same configuration, and I think that
makes it harder to compare the implications of these two configurations -
which was very much my objective in providing further discussion.


> Now, if we like, we can factor out the CAA records that appear in every
> example: those for the base domains staffie.dog, beagle.dog, terrier.dog,
> and hound.dog. That allows us to look at the differences between the worlds
> more closely, and see what CAA records are required beyond those:
>

I'm sorry. At this point, I'm no longer able to follow your logic, despite
having read this several times.