[cabfpub] Ballot 187 - Make CAA Checking Mandatory

Ryan Sleevi sleevi at google.com
Mon Feb 27 03:02:21 UTC 2017


On Sun, Feb 26, 2017 at 6:14 PM, Jacob Hoffman-Andrews via Public <
public at cabforum.org> wrote:

> Akamai could add this record to set a CAA policy:
>
> e3694.a.akamaiedge.net CAA 0 issue "symantec.com"
>
> I don't see an additional need to let Akamai set this policy at the
> akamaiedge.net level instead.
>

The difference here is whether you're requiring Akamai (or any other
provider) to do this.

You're imposing a particular deployment of DNS in order to gain advantage
of CAA, and I'm hesitant to suggest that the CA/Browser Forum is the right
venue for that - both in terms of scope and in terms of knowledge.

That is, put differently, the fact that Akamai bounces their customers
through an additional CNAME is by no means a requirement. Indeed, between
the HTTP/1.1 Host header and TLS's SNI, it's more inefficient to do so.

>From a management capability, setting a single CAA record on akamaiedge.net
makes sense.
>From a deployment perspective, avoiding the need for e3694.a.akamaiedge.net
makes sense.

So I think the behaviour - as specified - makes more sense.


> I also see "authorial intent" CAA as a little trickier to implement
> correctly than "erratum 4515
> <https://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4515>" CAA.
> Normally, a recursive resolver is responsible for chasing CNAMEs and
> detecting loops. Application code doesn't need to care about CNAMEs, only
> the final resource record. Implementing "authorial intent" CAA requires
> application code to specially handle CNAMEs and break loops. I think this
> is likely to introduce more bugs and inconsistent implementations.
>

I'm not sure I understand that argument or its relevance. As part of the
domain validation process, CAs must already be looking up explicit records
- e.g. not chasing CNAMEs - in order to yield the correct result. So I'm
not sure whether your scope of "application code" is talking about relying
parties (for which CAA is irrelevant) or CAs (for which CNAMEs and
non-recursion are already relevant).

If you did mean the latter, then I'm not sure how the conclusion is
supported - given that CAs are already implementing these checks (or, in
the discussion of 3.2.2.4 methods, can/will be for purposes of CNAME
vetting).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170226/5d29e3c0/attachment-0003.html>


More information about the Public mailing list