Re: [Spasm] CAA erratum 4515

[Ryan Sleevi <[e-mail]>]

On Sun, Mar 12, 2017 at 7:53 PM, Jacob Hoffman-Andrews <[e-mail]> wrote:

> > 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).
>
> So, back to the subjective evaluation: Now it's clear that the CDN in our
> scenario is the only one who can add CAA records. If a customer wants (1)
> they need cooperation from their CDN, and the CDN needs to implement a
> trampoline no matter what.
>
> *In the non-tree-climbing world*
>
> If a CDN wants to implement (3), they put in place a single CAA record and
> it doesn't impact (1) or (2). If the CDN wants to implement (1) or (2),
> they put in a CAA record at each of their CNAME targets. Neither policy
> affects the other in any way, assuming that CNAME targets are never base
> domains.
>
> *In the tree-climbing world*
>
> If a CDN wants to implement (3), they have to carefully understand CAA and
> be sure to add a separate "any" record to each of their CNAME targets. They
> also have to make sure to copy that CAA record to any new CNAME targets
> they create.
>
> I argue that this is less intuitive and more difficult than in the
> tree-climbing world.
>

Agreed. I think the lack of 'client' override - and apologies for my own
ignorance here, as I couldn't find where the exclusivity was stated that
ONLY a CNAME record may exist - is a pretty compelling argument against the
tree climbing.

While I disagree with some of the points below, I think this is the key
argument about why recursion-into-CNAME-and-tree-climb may not be desirable
- because it affords less control in the default configuration, and makes
it easier to misconfigure.


> More difficult, because it requires deploying extra CAA records to express
> a straightforward policy. Less intuitive, because most DNS-using
> applications don't care about the hostnames that are part of a CNAME chain,
> only the "final value" received from a recursive resolver. For instance,
> when looking up an A record, Chrome doesn't care about the CNAME aliases in
> between, only the final A record.
>

As an argument, I think this is unnecessary/unrelated, right? As in, you
can look up the existence *of* a CNAME record without transiting that CNAME
record. Put differently, and perhaps selfishly, it's "just" DNS :)


> Also, as a concrete example of the non-intuitiveness, Rob (one of the CAA
> authors) mentioned on the CA/Browser Forum list that he has had to
> double-check the lookup algorithm with Phill, his co-author.
>

I don't know how well this as an argument works. It's been nearly four
years since CAA was published before CAs got around to using it, nearly
seven years since it was first proposed, and the algorithm went through
several substantive revisions as part of the process :) I would say it's
reasonable to expect the people most involved and invested in it to have a
lot more mental state to sort through as to where "the process" finally
ended up ;)


> I've also been confused by the CAA lookup algorithm, as have my coworkers.
> I can't speak for Rob, but for me a big part of the confusion has been the
> fact that tree-climbing seems like an anomaly in the DNS world.
>

Perhaps in the DNS world, but it's SOP for the Certificate Authority world.
Consider the act of validating using approved email addresses - or
validating the 'registerable' domain. Both of these algorithms start with
an FQDN and then climb the tree until they are able to establish an
authortative link, and then everything below that tree is accepted as
validated.