Subject: [Spasm] CAA erratum 4515

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 9 Mar 2017 12:05:20 -0800

Good news! The CA/Browser forum made CAA checking mandatory, effective 8
September 2017
<https://cabforum.org/pipermail/public/2017-February/009722.html>. As
part of the process, we had a very interesting conversation (see bottom
for specific email links) about the processing algorithm specified in
RFC 6844 <https://tools.ietf.org/html/rfc6844#section-4>section 4
<https://tools.ietf.org/html/rfc6844#section-4> and how to handle
CNAMEs. Specifically, if there exists a set of records like so:

www.staffie.dog.        CNAME staffie.terrier.dog.

staffie.terrier.dog.    A 192.0.2.1

terrier.dog.            CAA 0 issue "happy-hacker-fake-ca.net"

Should issuance for www.staffie.dog require a CAA query for terrier.dog?
Or should it only require CAA queries for www.staffie.dog and
staffie.terrier.dog? It looks like we're not the first to be confused by
this. In October 2015, Tom Clegg filed erratum 4515
<https://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4515>,
changing the behavior. My position is that his approach is better, and
we should formally adopt it.

I'd like to define some terms so we can speak clearly:

 - Recursion: What a recursive resolver does: finding and querying
authoritative resolvers, and chasing CNAMEs.

 - Tree climbing: Looking up records for parent domains sequentially,
e.g. "www.staffie.dog", "staffie.dog", "dog".

The current RFC says that CA software should recurse, then tree climb on
any CNAME results, then tree climb on the original name, and repeat.

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

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

*The argument from CDNs don't want to do that*

Cloudflare helpfully chimed in on the original thread saying that they
wouldn't actually want to deploy a blanket CAA record for all their
customers, even though Cloudflare uses a well-defined set of CAs. That's
because doing so would prevent customers from getting their own
certificates from other CAs for non-HTTPS uses, or for subdomains like
party.www.staffie.dog. Even though the customers could override this by
setting their own CAA resource records, this is a hassle that Cloudflare
doesn't want to impose. Other CDNs are likely to feel similarly.

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

*Previous conversation*

  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009803.html>  /philliph
    at comodo.com/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009804.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009810.html>  /philliph
    at comodo.com/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009811.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009814.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009815.html>  /Ryan
    Sleevi/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009816.html>  /Peter
    Bowen/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009817.html>  /Ryan
    Sleevi/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009819.html>  /philliph
    at comodo.com/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009836.html>  /Jacob
    Hoffman-Andrews/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009837.html>  /Ryan
    Sleevi/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009838.html>  /Jacob
    Hoffman-Andrews/
  * [cabfpub] Ballot 187 - Make CAA Checking Mandatory 
    <https://cabforum.org/pipermail/public/2017-February/009839.html>  /Phillip
    Hallam-Baker/

/(whole thread:
/https://cabforum.org/pipermail/public/2017-February/thread.html)

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 9 Mar 2017 15:35:26 -0500

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

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

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

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 9 Mar 2017 13:07:53 -0800

On 03/09/2017 12:35 PM, Ryan Sleevi wrote:
> I want to be careful here restricting it to the notion of "CDNs",
I'm using CDN as a shorthand for "hosting provider or CDN." In the
Twitter example, the other stakeholders are the marketing department and
the contractor who develops the web content, neither of whom have CNAMEs
in the mix. Is there another entity type I'm missing?

> As you noted elsewhere, to effectively get this scenario, the operator
> of superbowl2017.twitter.com <http://superbowl2017.twitter.com> (which
> we'll call example.com <http://example.com>) would need to set up the
> destination of CNAME in such a way as to be able to appropriately
> provisioning) - that is, superbowl2017.twitter.example.com
> <http://superbowl2017.twitter.example.com> -  or, as you noted, would
> need to effectively set the CAA record as a 'wildcard' / for every
> customer.
I don't understand why example.com would need to set a per-customer
policy. If terrier.dog handles certificates for their customers, they
would do so with a limited set of CAs, and could set that as policy on
their domain names. If a specified customer like www.staffie.dog needs a
different policy, they can set it on their own hostname:

www.staffie.dog.        CAA 0 issue "sad-hacker-totally-real-ca.net"

I don't think trampolining is necessary to make this work.

If terrier.dog doesn't handle certificates, e.g., if they expect
customers to bring their own cert from any CA, then they can't
reasonably set a blanket policy for all their customers. In that
situation, I think it would similarly be up to the customer to set a CAA
policy on their own hostname if they wanted one, since the customer is
the one with the CA relationship.

---

From: Patrick Donahue <[email-masked]>
Date: Thu, 9 Mar 2017 13:45:26 -0800

I've previously shared my thoughts on this topic here:
https://cabforum.org/pipermail/public/2017-February/009850.html.

With respect to Jacob's initial tee-up:

Should issuance for www.staffie.dog require a CAA query for terrier.dog? Or
> should it only require CAA queries for www.staffie.dog and
> staffie.terrier.dog?

I'm a bit confused here as I would say "no" to the first question and I
would say that staffie.terrier.dog is irrelevant in the second part of the
question (but a CA may need to check staffie.dog if nothing set at
www.staffie.dog).

Can someone explain why the issuance check would need to do anything other
than:

   1. Look up CAA record for www.staffie.dog.
   1. If present
         1. Pass/fail based on contents.
      2. Else (i.e., if not present)
         1. Look up CAA record for staffie.dog.
            1. If present, pass/fail based on contents.
            2. If not present, pass.

If you control where www.staffie.dog points, you can do anything you want
with it content-wise. Why are we proposing tying certificate issuance to
the underlying (hosting provider/CDN/whatever) implementation?

If CAs are required to look up intermediate hostnames that are part of the
CNAME chain, we—as a large managed DNS provider—will be far less likely to
encourage CAA adoption and build tools to facilitate it. Otherwise we risk
not being able to issue certificates for our non-authoritative DNS
customers and, as a result, provide a poorer user experience while
simultaneously increasing our support costs.

For example, I've had calls the past couple of weeks with SaaS customers
that provide their app to hundreds of thousands of their end-customers on a
"vanity" hostname, e.g., app.saas-customer.com (rather than a non-"vanity"
hostname such as saas-customer.cloudflare-customer.com)

During onboarding, our customer instructs their end-customer to CNAME the
subdomain "app" (or whatever) to customers.cloudflare-customer.com, which
is reverse proxied through our network and thus facilitates doing HTTP DCV
at /.well-known/pki. Why should cloudflare-customer.com's CA preferences
for their own domain affect what certificates their end-customer can
receive?

On Thu, Mar 9, 2017 at 1:07 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> I'm using CDN as a shorthand for "hosting provider or CDN." In the Twitter
> example, the other stakeholders are the marketing department and the
> contractor who develops the web content, neither of whom have CNAMEs in the
> mix. Is there another entity type I'm missing?
>
> 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.
>
> policy. If terrier.dog handles certificates for their customers, they would
> do so with a limited set of CAs, and could set that as policy on their
> domain names. If a specified customer like www.staffie.dog needs a
> If terrier.dog doesn't handle certificates, e.g., if they expect customers
> to bring their own cert from any CA, then they can't reasonably set a
> blanket policy for all their customers. In that situation, I think it would
> similarly be up to the customer to set a CAA policy on their own hostname
> if they wanted one, since the customer is the one with the CA relationship.
>
>

-- 
Patrick R. Donahue
[email-masked]

PGP Fingerprint: 2E8D 5A38 682E EC00 C0F3  E7F2 D9BE 68D2 ABF3 6B24

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 9 Mar 2017 13:57:02 -0800

On 03/09/2017 01:45 PM, Patrick Donahue wrote:
> terrier.dog.            CAA 0 issue "happy-hacker-fake-ca.net
> <http://happy-hacker-fake-ca.net>"
>
>
>     Should issuance for www.staffie.dog require a CAA query for
>     terrier.dog? Or should it only require CAA queries for
>     www.staffie.dog and staffie.terrier.dog?
>
>
> I'm a bit confused here as I would say "no" to the first question and
> I would say that staffie.terrier.dog is irrelevant in the second part
> of the question (but a CA may need to check staffie.dog if nothing set
> at www.staffie.dog).
Sorry, I was a little fuzzy in my language here. There are two
questions: What queries does the CA make to its recursive resolver, and
what queries does the recursive resolver make?

If the CA queries "CAA www.staffie.dog.", the recursive resolver will
query the authoritative resolver for "CAA www.staffie.dog." Failing to
find it, the recursive resolver will then query the authoritative
resolver for "CNAME www.staffie.dog." The recursive resolver will follow
a sequence of CNAMEs, querying CAA (but not tree-climbing) at each step.
In this case there's just one step, and the recursive resolver queries
the authoritative resolver for "CAA staffie.terrier.dog." The recursive
resolver includes the result in its response to the CA software. This is
defined in RFC 1034 about DNS in general:

https://tools.ietf.org/html/rfc1034#section-3.6.2
> CNAME RRs cause special action in DNS software.  When a name server
> fails to find a desired RR in the resource set associated with the
> domain name, it checks to see if the resource set consists of a CNAME
> record with a matching class.  If so, the name server includes the CNAME
> record in the response and restarts the query at the domain name
> specified in the data field of the CNAME record.  The one exception to
> this rule is that queries which match the CNAME type are not restarted.

In other words, one CAA query to a recursive resolver can trigger
multiple CAA queries from the recursive resolver to the authoritative
resolver.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 12:02:57 -0500

> if they wanted one, since the customer is the one with the CA relationship.

The pronouns here (re: "they") make it a bit confusing to follow your
argument.

I'm also trying to stick to using domains reserved for purpose, rather than
use staffie.dog and terrier.dog. For sake of clarity, I'll rephrase it as:

From:

To:
www.example.com    CNAME staffie.example.net
staffie.example.net   A 192.0.2.1
example.net             CAA 0 issue "evil-ca.example.org"

Now that we've got that basic bit out, I'm going to try to briefly cover
the permutations of configurations here, with the introduction of some
terminology:

- Self-Managed = The domain operator of example.com handles certificate
acquisition for www.example.com
- Externally-Managed = The domain operator of example.net handles
certificate acquisition for www.example.com

and
- Recursive = As currently specified
- Non-Recursive = As Erratum 4515 proposes

Finally, one last dimension - whether or not a 'trampoline' is involved,
where
- Trampoline = example.com points their CNAME to a host at example.net that
is dedicated 'for them' (the 'staffie.example.net' case)

We end up with the following configurations:

- Self-Managed, Recursive, Trampoline'd
www.example.com  CNAME staffie.example.net
www.example.com  CAA 0 issue "good-ca.example.org"
example.com          CAA 0 issue "good-ca.example.org"
staffie.example.net A 192.0.2.1
example.net           CAA 0 issue "evil-ca.example.org"

- Externally-Managed, Recursive, Trampoline'd
www.example.com  CNAME staffie.example.net
example.com          CAA 0 issue "good-ca.example.org"
staffie.example.net  A 192.0.2.1
example.net            CAA 0 issue "evil-ca.example.org"

- Self-Managed, Non-Recursive, Trampolined
www.example.com  CNAME staffie.example.net
example.com          CAA 0 issue "good-ca.example.org"
staffie.example.net A 192.0.2.1
example.net           CAA 0 issue "evil-ca.example.org"

- Externally-Managed, Non-Recursive, Trampolined
EITHER:
www.example.com  CNAME staffie.example.net
example.com          CAA 0 issue "good-ca.example.org"
staffie.example.net A 192.0.2.1
staffie.example.net CAA 0 issue "evil-ca.example.org"
example.net           CAA 0 issue "evil-ca.example.org"

OR (and more problematically)

www.example.com  CNAME staffie.example.net
www.example.com  CAA 0 issue "evil-ca.example.org"
example.com          CAA 0 issue "good-ca.example.org"
staffie.example.net A 192.0.2.1
example.net           CAA 0 issue "evil-ca.example.org"

I say problematic here, because now example.com is responsible for
'tracking' example.net's configuration, and if example.net wants to change
configuration, it needs to notify example.com

For the non-trampoline case, the initial configuration looks something like:
www.example.com CNAME example.net
example.com         CAA 0 issue "good-ca.example.org"
example.net           A 192.0.2.1
example.net           CAA 0 issue "evil-ca.example.org"

For which we end up with the following permutations:
- Self-managed, recursive
www.example.com CNAME example.net
www.example.com CAA 0 issue "good-ca.example.org"
example.com         CAA 0 issue "good-ca.example.org"
example.net          A 192.0.2.1
example.net          CAA 0 issue "evil-ca.example.org"

- Externally-managed, recursive
www.example.com CNAME example.net
example.com         CAA 0 issue "good-ca.example.org"
example.net          A 192.0.2.1
example.net          CAA 0 issue "evil-ca.example.org"

- Self-managed, non-recursive
www.example.com CNAME example.net
www.example.com CAA 0 issue "good-ca.example.org"
example.com         CAA 0 issue "good-ca.example.org"
example.net          A 192.0.2.1
example.net          CAA 0 issue "evil-ca.example.org"

- Externally-managed, non-recursive
www.example.com CNAME example.net
example.com         CAA 0 issue "good-ca.example.org"
example.net          A 192.0.2.1
example.net          CAA 0 issue "evil-ca.example.org"

Have I reasonably summarized at least what the configurations would need to
look like, under the various algorithms? I figure it's probably important
to checkpoint here, before starting the subjective portion.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 10 Mar 2017 11:22:38 -0800

On 03/10/2017 09:02 AM, Ryan Sleevi wrote:
> I'm also trying to stick to using domains reserved for purpose, rather
> than use staffie.dog and terrier.dog.
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?

> - Self-Managed = The domain operator of example.com
> <http://example.com> handles certificate acquisition for
> www.example.com <http://www.example.com>
> - Externally-Managed = The domain operator of example.net
> <http://example.net> handles certificate acquisition for
> www.example.com <http://www.example.com>
Good terms, agreed.
> - Non-Recursive = As Erratum 4515 proposes
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.
> - Trampoline = example.com <http://example.com> points their CNAME to
> a host at example.net <http://example.net> that is dedicated 'for
> them' (the 'staffie.example.net <http://staffie.example.net>' case)
+1.

> We end up with the following configurations:
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 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 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:

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"

Self-managed, non-tree-climbing:
staffie.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"

Externally-managed, tree-climbing:

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

Externally-managed, non-tree-climbing:

staffie.dog.            CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
staffie.terrier.dog.    CAA 0 issue "enterprise.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
www.hound.dog.          CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"

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:

*Reduced examples*

Self-managed, tree-climbing:

www.staffie.dog.        CAA 0 issue "user-facing.ca"
www.beagle.dog.         CAA 0 issue "user-facing.ca"

Self-managed, non-tree-climbing:
none

Externally-managed, tree-climbing:

none

Externally-managed, non-tree-climbing:

staffie.terrier.dog.    CAA 0 issue "enterprise.ca"
www.hound.dog.          CAA 0 issue "enterprise.ca"

*Mixed-management*

Complicating things further, we additionally need to consider
"Mixed-management," the use case that Patrick described, where CDN
certificates are externally managed, but owners of user-facing domains
also buy their own certificates for domains that are CDN-managed. I
think in practice, all "Externally-managed" arrangements are actually
"Mixed-management." Under the assumption that most owners of user-facing
domains are unwilling or unable to deploy their own CAA records
overriding CDN CAA records, this may make deployment of blanket CAA
policies by CDNs impractical, regardless of tree-climbing or
non-tree-climbing.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 14:43:33 -0500

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

> 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
> Is that accurate? I'll adopt the CA names "user-facing.ca." and "
> enterprise.ca", since both our example CA names implied goodness or

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.

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

> 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.beagle.dog.        CNAME www.hound.dog.www.hound.dog.         A 192.0.2.2
>
>
> 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"
> 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.

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 10 Mar 2017 12:22:30 -0800

On 03/10/2017 11:43 AM, Ryan Sleevi wrote:
> 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?
>
> ambiguity, especially with your example of "enterprise.ca
> <http://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.
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.

>  (a) Every domain and subdomain in the example is covered by a CAA
Can you confirm whether this is an implicit goal in your examples?

>
>     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.
Sure, I'll re-explain: If you look at the examples, you'll find they all
have these four CAA entries in common:

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

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

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.

You and I agree that forcing CDNs to use trampolines to express a
certain CAA policy is undesirable. I disagree that trampolines are
necessary in either the tree climbing or the non-tree-climbing world.
Let's try to answer some specific questions:

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

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 16:18:40 -0500

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

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

> 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

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.

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 10 Mar 2017 13:50:51 -0800

On 03/10/2017 01:18 PM, Ryan Sleevi wrote:
> Which example? Are you talking about "example.net <http://example.net>
>           CAA 0 issue "evil-ca.example.org <http://evil-ca.example.org>" ?
Yep.
>
> 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
> <http://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 <http://www.example.net>") and co-hosts one or more
> customer domains ("terrier.example.net <http://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.
Great, looks like we're in agreement here. Personally I was taking it
for granted that CDNs (or hosting providers) often have a mix of
subdomains serving both their own sites and their customer sites, so
this didn't feel confusing, but I appreciate you clarifying it.
>
>  
>
>>     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
> 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
> <http://example.com>" and "example.net <http://example.net>" as two
> independent organizations with their own policies, for which they wish
> to express as efficiently and simply as possible.
Yep, that makes sense. One thing that might help is to detail that there
are actually three policies in play, that we've tended to squash into two:

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

The goal is that these can be set as three independent policies, without
unintended interactions.

Also, one thing I want to clarify: To what extent are you trying to
incentivize (2) and make it easy to do? I've been assuming that's a core
goal for you, but I may be misunderstanding that.
> customers with another policy, the trampoline is necessary or the
> customer has an additional configuration step.
This depends. Are the CDNs trying to support unique policies on a
per-customer basis, or a blanket policy as in (2) above? If it's a
blanket policy, no trampoline is needed. The CDN does need to have a
CNAME target that is not a base domain, but that target doesn't need to
be unique per-customer: i.e., not a trampoline.
> operates), while allowing their customers to operate with their own
> policy on the customer domains, the trampoline is necessary.
I don't think this case is significantly different than the above. One
policy gets set on the CDN's base domain, while the other policy gets
set on the CNAME target. If those policies happen to be the same, that's
fine.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 Mar 2017 17:51:58 -0500

On Fri, Mar 10, 2017 at 4:50 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> One thing that might help is to detail that there are actually three
> policies in play, that we've tended to squash into two:
>

Thanks for summarizing that, and I agree - it's really three different
things.

I don't even think I'm trying to incentivize (2), so much as try to figure
out the solution that allows the least changes to be made re: DNS records
to support the most number of variations of these policies, and to identify
where the most likely failure points are with respect to complexity.

Or, put differently, I want as many people to be able to set CAA policies
that work "out of the box" with minimal configuration. This, of course,
relies on a subjective interpretation of what the most likely scenarios
are, and I want to fully acknowledge that up-front. I think both
tree-climbing and non-tree-climbing can work, to be abundantly clear :)

> per-customer basis, or a blanket policy as in (2) above? If it's a blanket
> policy, no trampoline is needed. The CDN does need to have a CNAME target
> that is not a base domain, but that target doesn't need to be unique
> per-customer: i.e., not a trampoline.
>

Fair point - some indirection is necessary, but it's not necessarily
per-customer indirection.

> policy gets set on the CDN's base domain, while the other policy gets set
> on the CNAME target. If those policies happen to be the same, that's fine.
>

Fair point here as well. The complexity then comes from whether this
reflects current deployment, or whether it reflects a point of deployment
which would have to change to support. I think this is what you've
identified in (2).

The fewer things that need to change - and just work out of the box - the
better the deployment scenario for CAA looks. My instinct - perhaps
incorrectly - is that tree climbing allows fewer changes for the most
participants, not that tree climbing is an intrinsic necessity.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 10 Mar 2017 15:47:48 -0800

Cool, sounds like we are now on the same page, and can start talking in
more subjective terms.

On 03/10/2017 02:51 PM, Ryan Sleevi wrote:
>     3. Policy set by CDN for their own hostnames, which share the same
>     base domain as the CNAME targets used in (2).
>
I think (1) is easily handled by both tree-climbing and
non-tree-climbing implementations.

Both (2) and (3) are handled by both tree-climbing and non-tree-climbing
implementations with deployment of two CAA records. If the policies
happen to be the same, tree climbing allows the CDN to economize on CAA
records by deploying just one, on their base domain.

However, I think the policies are not likely to be the same. The
feedback we've gotten so far from Patrick is that Cloudflare is unlikely
to implement (2) because, like most CDNs and hosting providers, they are
effectively a Mixed-management setup.

So, what if a CDN wants to implement (3), but specifically avoid (2)?
This is very easy in the non-tree-climbing world: they set a single CAA
record on their base domain. In the tree-climbing world, it's very hard.
The CDN would need to specify a restrictive CAA record on their base
domain, and then another CAA record that specifies "Nevermind,
everything is allowed again" on their CNAME target, in order to block
tree-climbing to their root domain.

As far as I can see, RFC 6844 doesn't define a "Nevermind, everything is
allowed" CAA record. I think you could achieve the effect by creating a
CAA record containing a random tag that is not otherwise used, and
setting the critical bit to 0. But this is pretty hacky. Do you see a
better way to implement "(3) but not (2)" in the tree-climbing world?

>>     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.
>     I don't think this case is significantly different than the above.
>     One policy gets set on the CDN's base domain, while the other
>     policy gets set on the CNAME target. If those policies happen to
>     be the same, that's fine.
>
>
> reflects current deployment, or whether it reflects a point of
> deployment which would have to change to support. I think this is what
> you've identified in (2).
Is the question here whether CNAME targets are generally subdomains or
base domains? In my experience, almost always subdomains.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Mar 2017 20:19:04 +0000

> www.example.com  CAA 0 issue "good-ca.example.org"

This should not be possible, one surely can't have both CNAME and
CAA records for the same owner domain.

> www.example.com  CAA 0 issue "evil-ca.example.org"

Ditto.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 12 Mar 2017 00:03:58 +0000

> This should not be possible, one surely can't have both CNAME and CAA
> records for the same owner domain.

Right, if there's a CNAME record it can be the only record.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 12 Mar 2017 11:06:05 -0700

(Adding back the CC'ed participants who may not be subscribed to SPASM).

>> www.example.com  CAA 0 issue "evil-ca.example.org"

Ah, good point.

https://tools.ietf.org/html/rfc1912#section-2.4
> A CNAME record is not allowed to coexist with any other data.

customers' behalf.

In the tree-climbing world, given the above restriction on CNAMEs
coexisting, it would be impossible for a CDN to express "(3) without
(2)". Worse, if some CDN did express (3), it would be impossible for
their customers to opt out by setting CAA records on their own domains.
This would effectively bar CDNs from expressing (3) in the tree-climbing
world.

I think this is sufficient to say that tree climbing is undesirable.
What do other folks think?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 12 Mar 2017 14:43:55 -0400

If people want an escape hole 'anyone can issue' in CAA, I would rather do
it by defining generic domains:

ev.cabforum.org
dv.cabforum.org

That avoids the need to define new tags or update processing code. They are
simply domains that any WebTrust or ETSI audited CA issuing to those
requirements can issue.

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 12 Mar 2017 12:30:07 -0700

On Sun, Mar 12, 2017 at 11:43 AM, Phillip Hallam-Baker <
[email-masked]> wrote:

> That avoids the need to define new tags or update processing code. They
> are simply domains that any WebTrust or ETSI audited CA issuing to those
> requirements can issue.
>

I think there are several flaws with this argument:

- It's only applicable to set the of CAs bound by such a profile; that is,
a CA who is not WebTrust audited could just as easily issue such a
certificate without 'violating' either the letter or spirit of CAA, so it's
pointless to try to describe policy in that way
- The idea of introducing audits into the technical description is flawed,
in as much as audits are post-facto evaluations of operations. So it
wouldn't be a violation - of CAA or program requirements - for a CA with an
EV audit to issue such a certificate as DV if their CP/CPS dictated - it'd
only be post-facto misissuance.
- It still effectively limits the ability to express, for a given CA, the
desired policies of issuance. One organizations 'EV' can be another
organizations QCP+.

Let's keep to a simple principle - of simply saying 'any' - and leave
distinctions about certificate policies relevant to the set of CAs being
interacted with (e.g. as tags). That's the only way that really makes a
defensible - and auditable - security boundary, without relying on external
evaluations (whether or not a given CA is 'trusted' for EV, whether or not
a given CA is audited for EV, etc)

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 12 Mar 2017 12:33:44 -0700

> What do other folks think?

I think you're correct in that, in the absence of some form of trampoline -
and an 'any' policy - it can't be expressed.

However, am I mistaken in thinking that with those two - it could be? I
just want to make sure we know where the differences lie. Removing tree
climbing is arguably a substantive change to the specification, and would
likely require a document update. An 'any' expression and trampoline become
operational guidance, but don't require changing the specification.

Not to suggest one is more or less desirable than the other, but making
sure we've got a fully articulated set of guidance for "How you can
configure these cases with tree-climbing" and "How you can configure cases
without tree-climbing", and then evaluate their relative costs (to site
operators, to CAs, and 'process' wise). Does that sound reasonable?

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 12 Mar 2017 12:48:37 -0700

On 03/12/2017 12:33 PM, Ryan Sleevi wrote:
> On Sun, Mar 12, 2017 at 11:06 AM, Jacob Hoffman-Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> I think you're correct in that, in the absence of some form of
> trampoline - and an 'any' policy - it can't be expressed.
>
> However, am I mistaken in thinking that with those two - it could be?
Actually, thinking about it some more, all that's needed is an 'any'
policy. Even without a trampoline, the CDN only has to set the 'any'
policy on their CNAME target.

Separately: since we now realize that customers can't override CDN
policy by adding CAA records to their own zone, if a customer wants to
set their own CAA policy, the records have to be present on the CNAME
target. That is, the CDN would have to cooperate in adding that record.
Because different customers would no doubt want to express different
policies, the CDN would have to use a trampoline if they wanted to offer
per-customer CAA settings. However, this is true in both tree-climbing
and non-tree-climbing worlds. Do you agree?

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 12 Mar 2017 16:08:25 -0700

On Sun, Mar 12, 2017 at 12:48 PM, Jacob Hoffman-Andrews <[email-masked]>
wrote:
>
> Separately: since we now realize that customers can't override CDN policy
> by adding CAA records to their own zone, if a customer wants to set their
> own CAA policy, the records have to be present on the CNAME target. That
> is, the CDN would have to cooperate in adding that record. Because
> different customers would no doubt want to express different policies, the
> CDN would have to use a trampoline if they wanted to offer per-customer CAA
> settings. However, this is true in both tree-climbing and non-tree-climbing
> worlds. Do you agree?
>

That sounds correct

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 12 Mar 2017 16:53:53 -0700

customers' behalf.

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

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

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 15 Mar 2017 10:46:52 -0400

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Mar 2017 14:57:36 +0000

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

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

Sec 10.1 of RFC 2181, which clarifies 3.6.2 of RFC 1034 says (excerpt):
   An alias name (label of a CNAME record) may,
   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
   other data.

Hope this helps.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 15 Mar 2017 10:17:38 -0700

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.

> Did you mean "than in the *non* tree-climbing world?
Yep, thanks for spotting that.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 15 Mar 2017 21:09:37 +0000

On 15/03/17 14:46, Ryan Sleevi wrote:
<snip>
>     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.
>
>
> 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.
>
>
> 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

The DNS world is not my natural habitat.  ;-)

I don't think I had much additional mental state to sort through when I 
came to implement CAA for Comodo.  I read RFC6844 section 4, and then I 
re-read it numerous times, but I could not determine with certainty 
whether or not I should tree climb after following a CNAME.  So I sought 
clarification from Phill, since he was the primary author.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 16 Mar 2017 19:23:47 -0400

On Wed, Mar 15, 2017 at 1:17 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

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

Yeah, I think the issues related to expressing policies highlight why
tree-climbing is probably not desirable for actual CAA deployment.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 16 Mar 2017 19:50:50 -0400

> tree-climbing is probably not desirable for actual CAA deployment.

​You mean tree climbing or tree climbing on CNAME?

If the second, I concur.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 16 Mar 2017 17:20:54 -0700

> ​You mean tree climbing or tree climbing on CNAME?
Yep, we've been using "tree climbing" as shorthand for "tree climbing on
CNAME."

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Mar 2017 10:39:40 -0400

> Yep, we've been using "tree climbing" as shorthand for "tree climbing on

​So at this point, does anyone object to the ​following course of action:

​* Amend the CABForum ​'clarification' ballot to state that CAs must
implement RFC 6844 as amended by erratum 4515

* Write new ID to accept the substantive change described in Erratum 4515

* Request publication as a new RFC

​Now whether we do this inside or outside the WG is for the chairs and AD
to consider. I don't think this is currently a WG item.​ But if we have
concurrence and there is no real dispute, that probably isn't such an issue.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 17 Mar 2017 11:08:55 -0700

On 03/17/2017 07:39 AM, Phillip Hallam-Baker wrote:
> ​Now whether we do this inside or outside the WG is for the chairs and
> AD to consider. I don't think this is currently a WG item.​ But if we
> have concurrence and there is no real dispute, that probably isn't
> such an issue.
This seems like a reasonable course of action. The only quibble I have
is that, while erratum 4515 is the minimal change to express the
behavior we've agreed to, it leaves the algorithm section overly
detailed in a way that is potentially confusing to readers. I'd like to
propose this version, which relies on the RFC 1034 language for CNAME
resolution in order to clarify the behavior:

----- Proposal -----
   Let CAA(X) be the record set returned by performing a CAA record
query on the domain name X, according to the name server lookup
algorithm specified in RFC 1034 section 4.3.2 (in particular including
CNAME responses). Let P(X) be the domain name produced by removing the
leftmost label of X.

 - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise
 - If P(X) is the root domain '.', then R(X) is empty, otherwise
 - R(X) = R(P(X))

----- End proposal -----

For reference, current RFC 6844 with 4515 applied:

   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

   For example, if a certificate is requested for X.Y.Z the issuer will
   search for the relevant CAA record set in the following order:

      X.Y.Z

      Alias (X.Y.Z)

      Y.Z

      Alias (Y.Z)

      Z

      Alias (Z)

      Return Empty