[cabfpub] Ballot 187 - Make CAA Checking Mandatory

Peter Bowen pzb at amzn.com
Sun Feb 26 01:20:30 UTC 2017

> On Feb 25, 2017, at 4:57 PM, Ryan Sleevi <sleevi at google.com> wrote:
> On Sat, Feb 25, 2017 at 4:24 PM, Peter Bowen via Public <public at cabforum.org <mailto:public at cabforum.org>> wrote:
> I think that the DNAME checks are unnecessary, as 6672 (and other earlier RFCs) say that the name server synthesizes CNAME records based on the DNAME record.  That would leave:
>> Q(beta.shop.example.com <http://beta.shop.example.com/>, CAA) = <no answers>
>> Q(shop.example.com <http://shop.example.com/>, CAA) = CNAME, xmpl.cdn.bighost.com <http://xmpl.cdn.bighost.com/>.
>> Q(xmpl.cdn.bighost.com <http://xmpl.cdn.bighost.com/>, CAA) = CNAME, xmpl.cdnhost.xyz <http://xmpl.cdnhost.xyz/>.
>> Q(xmpl.cdnhost.xyz <http://xmpl.cdnhost.xyz/>, CAA) = <no answers>
>> Q(cdnhost.xyz <http://cdnhost.xyz/>, CAA) = <no answers>
>> Q(xyz, CAA) = <no answers>
>> Q(cdn.bighost.com <http://cdn.bighost.com/>, CAA) = <no answers>
>> Q(bighost.com <http://bighost.com/>, CAA) = <no answers>
>> Q(com, CAA) = <no answers>
>> Q(example.com <http://example.com/>, CAA) = <no answers>
>> # Not doing Q(com, CAA) as we already did it; if it was example.net <http://example.net/>, we would do Q(net, CAA) here
>> Result: no CAA record found
> I think this still will have unexpected results.
> See this real world example:
> ;; www.paypal.com <http://www.paypal.com/>.	IN	A
> www.paypal.com <http://www.paypal.com/>.	453	IN	CNAME	www.paypal.com.akadns.net <http://www.paypal.com.akadns.net/>.
> www.paypal.com.akadns.net <http://www.paypal.com.akadns.net/>.	30	IN	CNAME	ppdirect.paypal.com.akadns.net <http://ppdirect.paypal.com.akadns.net/>.
> ppdirect.paypal.com.akadns.net <http://ppdirect.paypal.com.akadns.net/>.	180	IN	CNAME	wlb.paypal.com.akadns.net <http://wlb.paypal.com.akadns.net/>.
> wlb.paypal.com.akadns.net <http://wlb.paypal.com.akadns.net/>.	30	IN	CNAME	www.paypal.com.edgekey.net <http://www.paypal.com.edgekey.net/>.
> www.paypal.com.edgekey.net <http://www.paypal.com.edgekey.net/>.	0	IN	CNAME	e3694.a.akamaiedge.net <http://e3694.a.akamaiedge.net/>.
> e3694.a.akamaiedge.net <http://e3694.a.akamaiedge.net/>.	20	IN	A
> If paypal.com <http://paypal.com/> sets a CAA record to symantec.com <http://symantec.com/>, but edgekey.net <http://edgekey.net/> has a CAA record to megaca.xyz <http://megaca.xyz/>, then the result is that Symantec cannot issue for www.paypal.com <http://www.paypal.com/> but MegaCA can (and only MegaCA can).  I don’t think that this is the logical result.
> While I do support CAA, I think we need to fix/clarify the handling of CNAMEs before mandating CAs follow CAA directives.
> Hi Peter,
> Can you explain why you don't believe this is the logical result? I think there's a perfectly logical argument that it is the desired result.
> Considering example.com <http://example.com/>, which might set a CAA record to symantec.com <http://symantec.com/>. This is because the example.com <http://example.com/> operator knows that all of the certificates they will obtain/purchase/etc will be from Symantec. Now imagine there's a subdomain - shop.example.com <http://shop.example.com/> . This domain is part of the example.com <http://example.com/> hierarchy, certainly, but it's in fact operated by "Shop Corp", a turnkey shopping portal that provides custom shopping portals for tens of thousands of sites. Shop Corp takes care of everything - hosting to payment processing to shipping - all with example.com <http://example.com/>'s branding.
> A key point of this being that shop.example.com <http://shop.example.com/> is not operated by the example.com <http://example.com/> operator, but instead CNAMEs over to shop.example.com.shopcorp.example, perhaps with as many hops as you've pointed out.
> shopcorp.example buys all of their certificates from MegaCA; in fact, they might exclusively use OV or EV certs so that "Example Corp" prominently shows when shopping shop.example.com <http://shop.example.com/>. So shopcorp.example has a CAA record of saying MegaCA.
> The logical consequence of this means that Symantec cannot issue for shop.example.com <http://shop.example.com/>, only MegaCA can. But that's exactly what is intended and logical.

Consider Public Key Pinning for HTTP.  If example.com sets a pin with “includeSubdomains”, then it applies to shop.example.com.  If shopcorp.example set a pin with includeSubdomains it does not apply to shop.example.com.  If 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.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170225/78bcc55d/attachment-0003.html>

More information about the Public mailing list