Re: [Spasm] CAA erratum 4515

[Ryan Sleevi <[e-mail]>]

On Thu, Mar 9, 2017 at 3:05 PM, Jacob Hoffman-Andrews <[e-mail]> wrote:

>
> *The argument from naturalness*
>
> I think the most natural way to think of CNAMEs is analogous to symlinks.
> If you `dig A www.staffie.dog` from a recursive resolver, you get back an
> IP address and don't need to care about the chain of intervening CNAMEs.
> The CAA RFC asks CA software to "peek inside" the CNAME chain for further
> processing, which is a significant difference from how other resource
> record types are handled.
>

I think it might help if you could define what you mean by "peek inside" -
I don't believe this is required in practice as defined, but perhaps it's
because of the textual description of the algorithm is not optimized. That
is, there are other formulations of the algorithm that can give the same
result - see below, courtesy of Andrew Ayer


>
>
> *The argument from ease of implementation *Right now, recursive resolvers
> take care of all CNAME chasing, including loop detection. To implement CAA
> as it is defined today, CA software needs to implement some moderately
> complex code to tree climb not only the original name, but also CNAME
> results. This means the CA software needs to implement its own loop
> detection as well. I think we're likely to see inconsistent and buggy
> results. On the other hand, erratum 4515 allows CA software to make three
> simple, predictable requests to its recursive resolver:
>
> CAA www.staffie.dog.
> CAA staffie.dog.
> CAA dog.
>

I disagree with the assertion that it requires moderately complex code;
this is something you can do with a dozen or so lines. Loop detection is a
necessity, I agree, and that's certainly true of the currently defined
algorithm, but a recursion limit is a sensible approach to this, and can
either be normatively specified here or within the profile enacted by the
CA/Browser Forum.

An example of this highlighted by Andrew Ayer is that you can rewrite the
current algorithm, while still obtaining equivalent results and the same
queries, as

R(X):
        if X is null:
                return null

        let caa = resolve('CAA', X)
        let target = resolve('CNAME', X)

        if caa is not null and target is null:
                return caa

        if target is not null:
                let recur = R(target)
                if recur is not null:
                        return recur

        return R(parent(X))

If you wanted to prevent loops, you could add the recursion limit there.



> *The argument from you don't need that*
>
> As I understand it, the argument for the current algorithm is that it
> makes it easier for CDNs to deploy CAA records. For instance, if
> terrier.dog is a CDN serving the terrier community, and they only request
> certificates from Happy Hacker Fake CA, they can easily express that policy
> by putting a CAA record on terrier.dog. I would argue that it's just as
> easy for terrier.dog to configure their authoritative resolver to return a
> CAA record for *.terrier.dog.
>

I want to be careful here restricting it to the notion of "CDNs", because
that limits the discussion to the Cloudflare/Akamai/Fastly case. I would
further advance that it applies to any form of delegation /
multi-stakeholder relationship, as the Twitter case you point out.

The question is largely one of operational deployment, and so I fully
admit, it's a subjective argument about a future scenario in which we have
incomplete data. My hope is to reduce the failure mode as much as possible,
now that sites can reliably deploy CAA and expect it to be observed, so
that we don't end up in situations where CAA is too complex to deploy.

I appreciate you sharing the Twitter case, because I think that speaks to
the concerns I have with erratum 4515.

*Hole punching and the includeSubDomains problem*
>
> Part of the debate is informed by deployment difficulties with HPKP
> includeSubDomains. For instance, in a previous job I deployed HTTPS at
> Twitter. We configured HPKP preloading with includeSubDomains on
> twitter.com, including all of the CAs that any of our CDNs used.
>
> Sometimes, for example, the marketing department, would hire a contractor
> to build a quickie website like superbowl2017.twitter.com. The contractor
> would have their own relationship with a hosting provider or CDN, who might
> use a CA not on the list. It would have been nice to be able to define hole
> punching, so superbowl2017.twitter.com could have its own definition of
> which CA keys are allowed. That's not possible with HPKP, but it is
> possible with CAA, intentionally.
>
> However, it's the tree climbing that gets us the hole punching property,
> not the alternating tree climb / recursion currently specified in RFC 6844.
> So adopting erratum 4515 would not break the hole punching property.
>

As you noted elsewhere, to effectively get this scenario, the operator of
superbowl2017.twitter.com (which we'll call example.com) would need to set
up the destination of CNAME in such a way as to be able to appropriately
express the per-customer policy (if Twitter handles certificate
provisioning) - that is, superbowl2017.twitter.example.com -  or, as you
noted, would need to effectively set the CAA record as a 'wildcard' / for
every customer.

Operationally, I totally accept that erratum 4515 can be a clear
definition. Practically, I think it creates greater operational deployment
challenges for such relationships, and as a result, requires greater effort
to deploy. In my mind, perhaps incorrectly, it's far easier to ensure the
CAA record on example.com than to handle the CAA "trampolining" for every
subdomain or sub-sub-domain that may be necessary.

With recursion, for example, if the marketing provider handled multiple
Superbowls, they might have superbowl2015.twitter.example.com,
superbowl2016.twitter.example.com, superbowl2017.twitter.example.com, and
set the CAA at twitter.example.com (or, if they handle certificate
provisioning, example.com). It makes it one less thing to remember to
change. I suspect that CDN cases like Cloudflare/Akamai/Fastly would have
no challenge with either approach, but I'm very concerned for the long-tail
of the ecosystem and the challenges it would present.