[cabfpub] Ballot 187 - Make CAA Checking Mandatory

[Peter Bowen]

> On Feb 25, 2017, at 11:14 AM, Phillip Hallam-Baker <phill at hallambaker.com> wrote:
> On Sat, Feb 25, 2017 at 12:45 PM, Peter Bowen via Public <public at cabforum.org <mailto:public at cabforum.org>> wrote:
> > On Feb 25, 2017, at 8:16 AM, philliph--- wrote:
> >> On Feb 24, 2017, at 9:17 PM, Peter Bowen <pzbowen at gmail.com <mailto:pzbowen at gmail.com>> wrote:
> >> On Fri, Feb 24, 2017 at 5:49 PM, philliph---wrote:
> >>> On the CAA recursive part, I am trying to track down why there is an
> >>> existing errata that makes a normative change with held for update status.
> >>>
> >>> The issue here is not in the PKIX part, it is what a CNAME/DNAME record
> >>> means. Different people in the DNS community took different positions. We
> >>> ended up concluding that the recursive interpretation was the appropriate
> >>> one, i.e. least likely to cause mistakes.
> >>
> >> I'm still confused.  Consider the following records (I'm leaving out
> >> class and TTL for simplicity:
> >>
> >> beta.shop.example.com <http://beta.shop.example.com/>. A 198.51.100.54
> >> shop.example.com <http://shop.example.com/>. CNAME xmpl.cdn.bighost.com <http://xmpl.cdn.bighost.com/>.
> >> example.com <http://example.com/>. A 198.51.100.4
> >> example.com <http://example.com/>. MX 10 mail1.mailhost.fast.
> >> example.com <http://example.com/>. NS ns1.cheapdns.biz <http://ns1.cheapdns.biz/>.
> >> example.com <http://example.com/>. NS ns2.cheapdns.org <http://ns2.cheapdns.org/>.
> >>
> >> cdn.bighost.com <http://cdn.bighost.com/>. DNAME cdnhost.xyz <http://cdnhost.xyz/>.
> >> bighost.com <http://bighost.com/>. NS ns1.dnshost.com <http://ns1.dnshost.com/>.
> >> bighost.com <http://bighost.com/>. NS ns2.dnshost.com <http://ns2.dnshost.com/>.
> >>
> >> xmpl.cdnhost.xyz <http://xmpl.cdnhost.xyz/>. A 203.0.113.231
> >> cdnhost.xyz <http://cdnhost.xyz/>. NS ns1.dnshost.com <http://ns1.dnshost.com/>.
> >> cdnhost.xyz <http://cdnhost.xyz/>. NS ns2.dnshost.com <http://ns2.dnshost.com/>.
> >>
> >> If a CA gets a certificate request that includes
> >> dNSName:beta.shop.example.com <http://beta.shop.example.com/>, what DNS queries must it make to check
> >> for CAA records?
>  
> Assume Q(name, type) = type, data means a lookup for name with a given type.
> 
> If any of the requests for Q(…, CAA) had returned a CAA answer, then this process would have stopped immediately and that data would be returned.
> 
> Does this match your expectation?
> 
> ​When we first started discussing CAA, the DNS world was disputing the legitimacy of DNAME altogether. ​Which led to this being published:
> 
> http://www.zytrax.com/books/dns/apd/rfc6672.txt <http://www.zytrax.com/books/dns/apd/rfc6672.txt>
> 
> The CAA draft was written rather earlier.
> 
> If people think we should change to remove the recursion, that is fine with me. The examples people gave at the time suggested recursion was the right approach.

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:

;; QUESTION SECTION:
;; www.paypal.com.	IN	A

;; ANSWER SECTION:
www.paypal.com.	453	IN	CNAME	www.paypal.com.akadns.net.
www.paypal.com.akadns.net.	30	IN	CNAME	ppdirect.paypal.com.akadns.net.
ppdirect.paypal.com.akadns.net.	180	IN	CNAME	wlb.paypal.com.akadns.net.
wlb.paypal.com.akadns.net.	30	IN	CNAME	www.paypal.com.edgekey.net.
www.paypal.com.edgekey.net.	0	IN	CNAME	e3694.a.akamaiedge.net.
e3694.a.akamaiedge.net.	20	IN	A	23.13.156.181

If paypal.com sets a CAA record to symantec.com, but edgekey.net has a CAA record to megaca.xyz, then the result is that Symantec cannot issue for 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.

Thanks,
Peter


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