<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ryan and Peter are both right. <div class=""><br class=""></div><div class="">This is where we got to the first time round. Whichever choice is made is right for some set of use cases and wrong for others. The underlying problem being that the DNS does not have a notion of administrative responsibility that is separate from maintaining a domain tree.</div><div class=""><br class=""></div><div class="">The situation was complicated by the fact that at the time we were doing the work, there was some dispute as to whether DNAME was really a DNS record as at the time it did not appear on the wire. The servers would synthesize CNAME records as required.What changed the situation was the deployment of DNSSEC.</div><div class=""><br class=""></div><div class="">There are three courses of action:</div><div class=""><br class=""></div><div class="">1) Accept CAA as specified in RFC6844, reject the existing errata held for document update to change this and add an errata to clarify that recursion is required.</div><div class=""><br class=""></div><div class="">2) Endorse the existing errata that causes CNAME/DNAME to be followed but eliminates the recursion, this would be a breaking change and require a new RFC but that should not be a major problem.</div><div class=""><br class=""></div><div class="">3) Write a new errata to remove references to CNAME/DNAME entirely as more trouble than they are worth.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">To clarify 2, the change would mean that if there was a CNAME from <a href="http://fred.example.com" class="">fred.example.com</a> to <a href="http://fred.example.net" class="">fred.example.net</a>, the search would include <a href="http://fred.example.net" class="">fred.example.net</a> but not <a href="http://example.net" class="">example.net</a>. If there was a DNAME from <a href="http://example.com" class="">example.com</a> to <a href="http://example.net" class="">example.net</a> the search would include <a href="http://example.net" class="">example.net</a> but not net.</div><div class=""><br class=""></div><div class="">[I am going to try to avoid answering this thread before having my morning coffee in future. The earlier example came out wrong, sorry.]</div><div class=""><br class=""></div><div class="">The key pinning issue is separate. I think the problem there is the attempt to use an infrastructure other than the DNS to make assertions about the DNS. Which is what I would like to revisit and fix at some point.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2017, at 8:53 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Feb 25, 2017 at 5:20 PM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">Consider Public Key Pinning for HTTP. If <a href="http://example.com/" target="_blank" class="">example.com</a> sets a pin with “includeSubdomains”, then it applies to <a href="http://shop.example.com/" target="_blank" class="">shop.example.com</a>. If shopcorp.example set a pin with includeSubdomains it does not apply to <a href="http://shop.example.com/" target="_blank" class="">shop.example.com</a>. If <a href="http://example.com/" target="_blank" class="">example.com</a> is pinning a CA key, they probably want to have a matching CAA record to help avoid confusion — they want the cert request rejected if they know resulting certificate isn’t going to work.</div></div></blockquote><div class=""><br class=""></div><div class="">For what it's worth, it's this behaviour that has been a significant blocker for sites deploying PKP, at least as part of the ongoing evangelism and discussions we've done during and following standardization.</div><div class=""><br class=""></div><div class="">I agree there's an asymmetry to PKP, but I also think that CAA offers a far, far more compelling solution than PKP, and so I'd rather make sure we get it right the second time :)</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I agree that your example could make sense, but it makes no sense in the common CDN case, as the CDN is just doing byte serving. The CDN probably does TLS decryption, but it might not; it would be very possible that the “CDN” is really just a better network that gets the encrypted packets to the origin server faster than would happen via the public internet. For example, you could be using Google Cloud Load Balancing in TCP mode. In this case there is zero reason for the CDN’s domain setting to control certificate issuance.</div></div></blockquote><div class=""><br class=""></div><div class="">Indeed, while some CDNs simply backhaul the connection on their own fiber versus relying on (unreliable) exchanges, I would again suggest the majority service here is that the CDN is doing the certificate issuance (... and also commonly the domain management).</div><div class=""><br class=""></div><div class="">I think we're actually in agreement in that these are somewhat conflicting goals, and I raised the example as it sounded like you hadn't considered it, when you mentioned it wasn't logical to behave like that. It is logical, but it's a question about which case to optimize for - again, acknowledging the tradeoffs involved here.</div><div class=""><br class=""></div><div class="">The reason for which I take the position I do - that is, the recurse-into-alias-before-resuming approach (as I believe it specified / intended to be) - is that by adopting the PKP-like top-down approach, then it means any time you want to introduce a CDN or point of delegation (who might use MegaCA), you need to allow MegaCA for your entire domain hierarchy at the upper levels. You can kinda work around this (e.g. <a href="http://shop.cdn.example.com/" class="">shop.cdn.example.com</a>, where shop is a CNAME, but there's a CAA record for <a href="http://cdn.example.com/" class="">cdn.example.com</a> that is different than the CAA record for <a href="http://example.com/" class="">example.com</a>), but then that puts more burden on the site operator to update when the CDN makes operational changes.</div><div class=""><br class=""></div><div class="">By going the approach I suggest, it means you only introduce any additional 'risk' to the ecosystem when a site operator introduces CNAMEs. Since I take the view that CDNs are already an additional threat vector regardless of CAA, and further that CNAMEs are most commonly to support CDNs, then I'm ok with the loss of absolute control that it affords the <a href="http://example.com/" class="">example.com</a> operator, because I think they've already lost control.</div></div></div></div>
_______________________________________________<br class="">Public mailing list<br class=""><a href="mailto:Public@cabforum.org" class="">Public@cabforum.org</a><br class="">https://cabforum.org/mailman/listinfo/public<br class=""></div></blockquote></div><br class=""></div></body></html>