<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 25, 2017 at 5:20 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">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"><div>Consider Public Key Pinning for HTTP.  If <a href="http://example.com" target="_blank">example.com</a> sets a pin with “includeSubdomains”, then it applies to <a href="http://shop.example.com" target="_blank">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">shop.example.com</a>.  If <a href="http://example.com" target="_blank">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><br></div><div>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><br></div><div>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> </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"><div>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><br></div><div>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><br></div><div>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><br></div><div>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">shop.cdn.example.com</a>, where shop is a CNAME, but there's a CAA record for <a href="http://cdn.example.com">cdn.example.com</a> that is different than the CAA record for <a href="http://example.com">example.com</a>), but then that puts more burden on the site operator to update when the CDN makes operational changes.</div><div><br></div><div>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">example.com</a> operator, because I think they've already lost control.</div></div></div></div>