[cabfpub] Ballot 187 - Make CAA Checking Mandatory

[philliph at comodo.com]

Ryan and Peter are both right. 

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.

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.

There are three courses of action:

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.

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.

3) Write a new errata to remove references to CNAME/DNAME entirely as more trouble than they are worth.


To clarify 2, the change would mean that if there was a CNAME from fred.example.com to fred.example.net, the search would include fred.example.net but not example.net. If there was a DNAME from example.com to example.net the search would include example.net but not net.

[I am going to try to avoid answering this thread before having my morning coffee in future. The earlier example came out wrong, sorry.]

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.



> On Feb 25, 2017, at 8:53 PM, Ryan Sleevi via Public <public at cabforum.org> wrote:
> 
> 
> 
> On Sat, Feb 25, 2017 at 5:20 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> Consider Public Key Pinning for HTTP.  If example.com <http://example.com/> sets a pin with “includeSubdomains”, then it applies to shop.example.com <http://shop.example.com/>.  If shopcorp.example set a pin with includeSubdomains it does not apply to shop.example.com <http://shop.example.com/>.  If example.com <http://example.com/> 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.
> 
> 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.
> 
> 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 :)
>  
> 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.
> 
> 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).
> 
> 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.
> 
> 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. shop.cdn.example.com <http://shop.cdn.example.com/>, where shop is a CNAME, but there's a CAA record for cdn.example.com <http://cdn.example.com/> that is different than the CAA record for example.com <http://example.com/>), but then that puts more burden on the site operator to update when the CDN makes operational changes.
> 
> 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 example.com <http://example.com/> operator, because I think they've already lost control.
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170226/bfda364e/attachment.html>