On Sat, Sep 9, 2017 at 3:57 AM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > >> On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> In all three of these cases, the "domain's zone does not have a DNSSEC >> validation chain to the ICANN root" -- I requested SOA, DNSKEY, NS, >> and CAA records types for each zone and in no case did I get a >> response that had a valid DNSSEC chain to the ICANN root. > > This comes down to what exactly “does not have a valid DNSSEC chain” means. > > I had assumed that given the reference to DNSSEC in the BRs that the relevant > DNSSEC RFCs were incorporated by reference via RFC 6844 and that DNSSEC > validation is required. However, this is not entirely the case, using DNSSEC > for CAA lookups is only RECOMMENDED in section 4.1 and explicitly “not > required.” Which means this is all pretty pointless. The existence or > non-existence of DNSSEC records doesn’t matter if there is no requirement to > use them. > > Given this context, I think that your interpretation of this clause is not > problematic since there is no requirement anywhere to use DNSSEC. > > I think this should probably be taken to the CAB Forum for a ballot to either: > > 1) purge this reference to DNSSEC from the BRs making it entirely optional > instead of just having this pointless check; or > 2) add a requirement to the BRs that DNSSEC validation be used from the ICANN > root for CAA lookups and then tweak the relevant clause to only allow lookup > failures if there is a valid non-existence proof of DNSSEC records in the > chain that allows an insecure lookup. > > None of my comments in this thread should be interpreted as support for > DNSSEC :)
My recollection from the discussion that led to the ballot was that this line in the BRs was specifically to create a special hard fail if the zone was properly signed but the server returned an error when looking up CAA records. As a big of background, in order to be properly signed, the zone must have unexpired signatures over at least the SOA record (as this is the minimal allowed signature when using NSEC3 with Opt-Out). Additionally this case never exists with zones signed using NSEC or NSEC3 without opt-out, as they will provide a either a denial of existence or a signature that disclaims CAA record type existence. So this bullet in the BRs only triggers when: - SOA record has a valid signature - There is a DNSKEY for the zone that matches the DS record in the parent zone - The DS record in the parent zone is signed - The above three are true for all zones back to the root zone - The request for a CAA record for the QNAME returns an error - The request for DNSSEC information for the QNAME succeeds - The DNSSEC information does not provide information on the name (e.g. is for records before and after but the opt-out flag is set) In all of these are present, the CA may not issue. If the DNSSEC information is valid and says there is a CAA record in the type bitmaps but the server returned an error for CAA records, then the CA must not issue. I don't think your tests cover either of these cases. I think any other case allows issuance as it follows the path of no CAA record. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
