[cabf_validation] CAA - Require Queries to Authoritative NS

[Quirin Scheitle]

Hi,

we had closely investigated this for our study [1] and had decided that the "Data cached by third parties MUST NOT be relied on” is the determining one, i.e. CAs must contact the authoritative name servers. We agree that the language could be more clear in that RFC section. 
We have tested resolver behaviour for all CAs tested in our study and found 1 CA to rely solely on a public resolver. They have acknowledged this as a problem and fixed it. 

I would expect that (also from the untested CAs) few use public resolvers, as these also do not give the level of feedback needed (timeout, timeout w/ dnssec, malformed record, signature expired, … will probably be mingled into SERVFAIL).

Kind regards
Quirin

[1] https://caastudy.github.io

> On 9. Jan 2018, at 20:11, Tim Hollebeek via Validation <validation at cabforum.org> wrote:
> 
> I thought this was wrong, but I double-checked and they’re right: querying the authoritative name server is a SHOULD in the RFC.  We would support fixing that in the BRs.
>  
> However, that said, the RFC does have “Data cached by third parties MUST NOT be relied on”.  Any CAs currently using third-party DNS should be very careful as most probably do cache.
>  
> In fact, why not add 3.2.2.8 to the list of sections that cannot be performed by a Delegated Third Party?  These sorts of technical validation checks need to be completely under the control of the CA.
>  
> -Tim
>  
> From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Wayne Thayer via Validation
> Sent: Tuesday, January 9, 2018 10:32 AM
> To: CA/Browser Forum Validation WG List <validation at cabforum.org>
> Subject: [cabf_validation] CAA - Require Queries to Authoritative NS
>  
> I just became aware of this CloudFlare blog on CAA implementation issues: https://blog.cloudflare.com/caa-of-the-wild/
>  
> Much of what they describe are issues that we've discussed in the past, but I don't recall this one:
>  
> There’s an additional security gap in that neither the RFC nor the BR indicate where the issuing CA should query for CAA records. It is acceptable within the current standards to query any DNS recursor for these records as well as the authoritative DNS provider for a domain. For example, an issuing CA could query Google’s Public DNS or a DNS recursor provided by their ISP for these responses. This enables compromised DNS recursors or one run by a rogue operator to alter these responses, either denying issuance or allowing issuance by a CA not approved by the domain owner. The RFC and BR should be amended so that an issuing CA must always query these records at the authoritative provider to close this gap.
>  
> Some CAs are already doing this, so I propose we make it a requirement, at least in the case where the CA is going to treat a lookup failure as permission to issue.
>  
> Thanks,
>  
> Wayne
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2855 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180110/54562d1f/attachment-0001.p7s>