Re: [Spasm] CAA erratum 4515

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

On 03/15/2017 07:46 AM, Ryan Sleevi wrote:
> 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.
Great. So should I take it that you are now in support of revising the
RFC to specify non-tree-climbing behavior?

> 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 :)
Ultimately, as long as we agree, I'm not too concerned about which
argument carried the day. For me, the argument about being "intuitive"
or "similar to other DNS operations" is important for the same reason
you cite above: I think doing otherwise makes it easier to misconfigure.

> 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.
Yes, but Certificate Authorities certainly don't tree-climb on CNAME
targets, which is what this conversation is about.


On 03/15/2017 07:57 AM, Salz, Rich wrote:
>> I argue that this is less intuitive and more difficult than in the tree-climbing world. 
> Did you mean "than in the *non* tree-climbing world?
Yep, thanks for spotting that.