[cabf_validation] CAA - Require Queries to Authoritative NS

[Tim Hollebeek]

Yup, most CAs are doing the right thing for exactly the reasons you described.

But I'm sure the one you found isn't the only one who isn't, and it'd be great
to fix the BRs to be completely clear on this point.

-Tim

> -----Original Message-----
> From: Quirin Scheitle [mailto:scheitle at net.in.tum.de]
> Sent: Wednesday, January 10, 2018 8:23 AM
> To: CA/Browser Forum Validation WG List <validation at cabforum.org>
> Cc: Wayne Thayer <wthayer at mozilla.com>; Tim Hollebeek
> <tim.hollebeek at digicert.com>
> Subject: Re: [cabf_validation] CAA - Require Queries to Authoritative NS
> 
> 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: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180110/0abbcf6e/attachment.p7s>