<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 26, 2017 at 6:14 PM, Jacob Hoffman-Andrews via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Akamai could add this record to set a CAA policy:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://e3694.a.akamaiedge.net" target="_blank">e3694.a.akamaiedge.net</a> CAA 0 issue "<a href="http://symantec.com" target="_blank">symantec.com</a>"</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't see an additional need to let Akamai set this policy at the <a href="http://akamaiedge.net" target="_blank">akamaiedge.net</a> level instead.</div></div></blockquote><div><br></div><div>The difference here is whether you're requiring Akamai (or any other provider) to do this.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>From a management capability, setting a single CAA record on <a href="http://akamaiedge.net">akamaiedge.net</a> makes sense.</div><div>From a deployment perspective, avoiding the need for <a href="http://e3694.a.akamaiedge.net">e3694.a.akamaiedge.net</a> makes sense.</div><div><br></div><div>So I think the behaviour - as specified - makes more sense.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">I also see "authorial intent" CAA as a little trickier to implement correctly than "<a href="https://www.rfc-editor.org/errata_search.php?rfc=6844&eid=4515" target="_blank">erratum 4515</a>" 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.</div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div></div></div></div>