<div dir="ltr"><div class="gmail_extra"><span style="font-size:12.8px">Resharing on behalf of </span>Patrick Donahue <<a href="mailto:pat@cloudflare.com">pat@cloudflare.com</a>>, at Cloudflare.</div><div class="gmail_extra"><span class="gmail-im" style="font-size:12.8px"><br></span></div><div class="gmail_extra"><span class="gmail-im" style="font-size:12.8px">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></span><span class="gmail-im" style="font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">I agree that we want CDNs and hosting providers to be able to easily set default CAA policies for hostnames that are CNAMEd to them. They know which CAs they actually use, and usually terminate TLS, so they can accurately set policy for a large number of domains at once with very little disruption.</div></div></blockquote><div><br></div></span><div style="font-size:12.8px">For the most part. As both an authoritative DNS provider and Applicant of certificates on behalf of our customers, we have to be careful here in i) setting safe defaults and ii) helping users that do explicitly want CAA to create records that don't lock out their other legitimate issuance. As you point out in your footnote, they may need to acquire certificates for non-HTTPS purposes (or for HTTPS that doesn't route through their CDN for whatever reason); this is especially true in large and/or decentralized organizations.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">While we'd love to adopt CAA en masse, we can't simply add default CAA records. Instead, what we plan to do is design our DNS interface to allow users to easily specify one or more of the following for their domain (and/or subdomain, etc.):</div><div style="font-size:12.8px"><ol><li style="margin-left:15px">Allow issuance from Cloudflare's current Universal SSL and Dedicated SSL partners (i.e., several CAs on this mailing list)</li><li style="margin-left:15px">Allow issuance from CAs that issued the certificates they've uploaded to us (or will upload in the future)</li><ol><li style="margin-left:15px">As discussed on Twitter with Gerv and Jacob, there's no easy or unambiguous way to automate this lookup. Relatedly, I am a fan of Ryan's suggestion on making the CPS be machine-readable so these CAA values can be extracted by code rather than humans.</li></ol><li style="margin-left:15px">Allow issuance based on the exact CAA record that I manually set.</li></ol></div><div style="font-size:12.8px">In options #1 and #2 above, we intend to update CAA records dynamically as this list of user-permitted CAs evolves. We expect option #3 will be used by more "advanced" users (and likely will roll out first to accommodate the requests we're fielding from early adopters).</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">And while I agree with all of Ryan's points related to this specific situation being a business and not technical concern, option #3 can be used to accommodate Matt's use case of preventing automated issuance during onboarding (or thereafter). Expanding on this a bit: because we prompt for existing (and new) DNS records prior to providing authoritative nameservers to be set at the registrar, users wishing to prevent automated issuance could set CAA at the outset—and the CAs we automatically request issuance from would see this record/hopefully follow the BRs.</div><span class="gmail-im" style="font-size:12.8px"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">It's also useful for domain owners to be able to punch out exceptions to a CAA record specified by their CDN for many reasons[1]. CAA's left-to-right evaluation order gives both of these properties.</div><div class="gmail_extra"><br></div><div class="gmail_extra">However, I think the <span style="font-size:12.8px">recurse-into-alias-before-</span><span style="font-size:12.8px"><wbr>resuming ("authorial intent") version of CAA is not needed to accomplish those goals. For instance, in Peter's example:</span></div><span class="gmail-m_-3087182167007274359gmail-"><div class="gmail_extra"><br></div><div class="gmail_extra"><div style="font-size:12.8px"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">;; ANSWER SECTION:<br><a href="http://www.paypal.com/" target="_blank">www.paypal.com</a>.<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">        </span>453<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">  </span>IN<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>CNAME<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">        </span><a href="http://www.paypal.com.akadns.net/" target="_blank">www.paypal.com.akadns.net</a>.<br><a href="http://www.paypal.com.akadns.net/" target="_blank">www.paypal.com.akadns.net</a>.<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">       </span>30<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>IN<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>CNAME<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">        </span><a href="http://ppdirect.paypal.com.akadns.net/" target="_blank">ppdirect.paypal.com.akadns.net</a><wbr>.<br><a href="http://ppdirect.paypal.com.akadns.net/" target="_blank">ppdirect.paypal.com.akadns.net</a><wbr>.<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">     </span>180<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">  </span>IN<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>CNAME<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">        </span><a href="http://wlb.paypal.com.akadns.net/" target="_blank">wlb.paypal.com.akadns.net</a>.<br><a href="http://wlb.paypal.com.akadns.net/" target="_blank">wlb.paypal.com.akadns.net</a>.<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">       </span>30<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>IN<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>CNAME<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">        </span><a href="http://www.paypal.com.edgekey.net/" target="_blank">www.paypal.com.edgekey.net</a>.<br><a href="http://www.paypal.com.edgekey.net/" target="_blank">www.paypal.com.edgekey.net</a>.<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>0<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">    </span>IN<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>CNAME<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">        </span><a href="http://e3694.a.akamaiedge.net/" target="_blank">e3694.a.akamaiedge.net</a>.<br><a href="http://e3694.a.akamaiedge.net/" target="_blank">e3694.a.akamaiedge.net</a>.<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>20<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>IN<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">   </span>A<span class="gmail-m_-3087182167007274359gmail-m_-991586851237317795gmail-m_8942493008604600511Apple-tab-span" style="white-space:pre-wrap">    </span>23.13.156.181</blockquote></div></div><div class="gmail_extra"><br></div></span><div class="gmail_extra">Akamai could add this record to set a CAA policy:</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 class="gmail_extra"><br></div><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 class="gmail_extra"><br></div></div></blockquote><div><br></div></span><div style="font-size:12.8px">Agreed. And I don't really see what we're trying to accomplish here. How a domain resolves—whether directly to an A/AAA record or through a series of CNAMEs—is an implementation detail for that domain owner, not (in my opinion) relevant to CAA.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In the PayPal example above, a certificate is being requested with a SAN of "<a href="http://www.paypal.com/" target="_blank">www.paypal.com</a>". Why would a CA need to check anything other than CAA records set on the nameservers authoritative for "<a href="http://paypal.com/" target="_blank">paypal.com</a>" and "<a href="http://www.paypal.com/" target="_blank">www.paypal.com</a>"? Same answer applies for Peter's original question: "If a CA gets a certificate request that includes dNSName:<a href="http://beta.shop.example.com/" target="_blank">beta.shop.example.com</a>, what DNS queries must it make to check for CAA records?"</div></div></div>