[cabfpub] DNSSEC validation for CAA record lookup failure

[Geoff Keating]

> On Sep 14, 2017, at 2:37 PM, Peter Bowen <pzb at amzn.com> wrote:
> 
> 
>> On Sep 14, 2017, at 10:02 AM, Geoff Keating via Public <public at cabforum.org> wrote:
>> 
>> At the moment the BRs say:
>> 
>> CAs are permitted to treat a record lookup failure as permission to issue if:
>> 
>> the failure is outside the CA's infrastructure;
>> 
>> the lookup has been retried at least once; and
>> 
>> the domain's zone does not have a DNSSEC validation chain to the ICANN root. 
>> 
>> I suggest replacing the last item with “the record being looked up is classified as ‘Insecure’ under RFC 4035 section 4.3, as amended.”
>> 
>> The most common case of this will be that the record being looked up is a CAA record for, say, example.com; the .com servers have been contacted successfully, producing authenticated NS records for example.com, but the example.com name servers cannot be contacted; and the .com servers have provided authenticated denial of existence for a DS record for example.com.  This is covered in RFC 4035 section 5.2, “If the validator authenticates an NSEC RRset that proves that no DS RRset is present for this zone, then there is no authentication path leading from the parent to the child.”
> 
> Geoff,
> 
> This covers the “affirmatively insecure” case — that is a signed response affirmatively indicates there are no DS records for a given name but there are NS records for the same name.
> 
> However many of the cases are not as clear, especially in the face of NSEC3 with opt-out.  What if there is a DS record but the child zone returns an answer that is covered in an opt-out gap?  

> What if the delegation without DS is covered in opt-out?  Are these both affirmatively insecure?

If you happen to have that NSEC3 record, it is proof the lookup is insecure; but if there is a DS record, and you get a RRSIG for it, you can also do a secure lookup.

This sounds weird but it is still less weird than having both a NSSEC record that proves there is no DS record, and the signed DS record.

This can happen in normal operation if the NSEC/NSEC3 record is generated shortly before the DS record is added and hasn’t expired yet, for example.

> Also, take a look at https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439  There is discussion there that highlights another challenge: what happens in error cases.  How should CAs handle a case where they are trying to get data for beta.shop.example.com, example.com has a DS record in the com zone, but there are no DNSKEY records for example.com in the example.com zone?  We don’t know if shop.example.com is insecure or secure.

At this point, you’ll have queried the .com servers for the CAA record for beta.shop.example.com, and been given a referral to the example.com servers containing NS and DS records, and not a NSEC or NSEC3 response proving there is no DS record. Then you try to query the example.com nameservers, for either the CAA or DNSKEY, and it fails.

The exemption does not apply because you can’t prove that the lookup that failed is of a record classified as ‘insecure’.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170914/67523366/attachment-0003.html>