> On Sep 14, 2017, at 2:37 PM, Peter Bowen <[email protected]> wrote:
>
>
>> On Sep 14, 2017, at 10:02 AM, Geoff Keating via Public <[email protected]>
>> 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’.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
