<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Sep 14, 2017, at 2:37 PM, Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 14, 2017, at 10:02 AM, Geoff Keating via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">At the moment the BRs say:<div class=""><br class=""></div><div class="">
<div class="page" title="Page 24">
<div class="layoutArea">
<div class="column"><p class=""><span style="font-size: 10.000000pt; font-family: 'Cambria'" class="">CAs are permitted to treat a record lookup failure as permission to issue if:
</span></p>
<ul class="">
<li style="font-size: 10.000000pt; font-family: 'Cambria'" class=""><p class=""><span style="font-size: 10pt;" class="">the failure is outside the CA's infrastructure;
</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Cambria'" class=""><p class=""><span style="font-size: 10pt;" class="">the lookup has been retried at least once; and
</span></p>
</li>
<li style="font-size: 10.000000pt; font-family: 'Cambria'" class=""><p class=""><span style="font-size: 10pt;" class="">the domain's zone does not have a DNSSEC validation chain to the ICANN root. </span></p>
</li>
</ul>
</div>
</div>
</div></div><div class="">I suggest replacing the last item with “the record being looked up is classified as ‘Insecure’ under RFC 4035 section 4.3, as amended.”</div><div class=""><br class=""></div><div class="">The most common case of this will be that the record being looked up is a CAA record for, say, <a href="http://example.com/" class="">example.com</a>; the .com servers have been contacted successfully, producing authenticated NS records for <a href="http://example.com/" class="">example.com</a>, but the <a href="http://example.com/" class="">example.com</a> name servers cannot be contacted; and the .com servers have provided authenticated denial of existence for a DS record for <a href="http://example.com/" class="">example.com</a>. 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.”</div></div></div></blockquote><br class=""></div><div>Geoff,</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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? </div></div></blockquote><div><br></div><blockquote type="cite"><div><div>What if the delegation without DS is covered in opt-out? Are these both affirmatively insecure?</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><br><blockquote type="cite"><div>Also, take a look at <a href="https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439" class="">https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439</a> 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 <a href="http://beta.shop.example.com" class="">beta.shop.example.com</a>, <a href="http://example.com" class="">example.com</a> has a DS record in the com zone, but there are no DNSKEY records for <a href="http://example.com" class="">example.com</a> in the <a href="http://example.com" class="">example.com</a> zone? We don’t know if <a href="http://shop.example.com" class="">shop.example.com</a> is insecure or secure.</div></blockquote><div><br></div><div>At this point, you’ll have queried the .com servers for the CAA record for <a href="http://beta.shop.example.com">beta.shop.example.com</a>, and been given a referral to the <a href="http://example.com">example.com</a> 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 <a href="http://example.com">example.com</a> nameservers, for either the CAA or DNSKEY, and it fails.</div><div><br></div><div>The exemption does not apply because you can’t prove that the lookup that failed is of a record classified as ‘insecure’.</div></body></html>