[cabf_validation] CAA - Require Queries to Authoritative NS

[Tim Hollebeek]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180109/a002b9ef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180109/a002b9ef/attachment.p7s>