On Sat, 9 Sep 2017 08:49:01 -0700 Peter Bowen via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> 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. Your recollection is not consistent with the most recent cabfpub thread on the topic: https://cabforum.org/pipermail/public/2017-August/011800.html > As a big of background, in order to be properly signed [...] The BRs do not say that the zone has to be "properly signed" for this line to trigger. Nor do they require a "valid chain" of signatures from particular records in the zone to the root, as you suggested in another email. Rather, the BRs say the line triggers if there is "a DNSSEC validation chain to the ICANN root." A "validation chain" doesn't mean signatures, but rather the information needed to validate the zone. "Validation chain" is not the precise term that DNSSEC uses, but the synonymous term "authentication chain" is defined by RFC 4033 (incorporated by reference from RFC 6844) as follows: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of signed data, with each link in the chain vouching for the next. A DNSKEY RR is used to verify the signature covering a DS RR and allows the DS RR to be authenticated. The DS RR contains a hash of another DNSKEY RR and this new DNSKEY RR is authenticated by matching the hash in the DS RR. This new DNSKEY RR in turn authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in this set may be used to authenticate another DS RR, and so forth until the chain finally ends with a DNSKEY RR whose corresponding private key signs the desired DNS data. For example, the root DNSKEY RRset can be used to authenticate the DS RRset for "example." The "example." DS RRset contains a hash that matches some "example." DNSKEY, and this DNSKEY's corresponding private key signs the "example." DNSKEY RRset. Private key counterparts of the "example." DNSKEY RRset sign data records such as "www.example." and DS RRs for delegations such as "subzone.example." Although the chain ends with a DNSKEY RR in the zone itself, you don't need to successfully look up that DNSKEY to know that a chain exists: the presence of a DS record in the parent zone means that the corresponding DNSKEY RR _has_ to exist. This is made clear by the totality of RFC4033, particularly sections 5 and 12. So for the purposes of determining if a zone has a validation/authentication chain to the ICANN root, the CA should look for the DS record in the parent zones. All of this is clear from the relevant DNSSEC RFCs, it's how DNSSEC is widely understood to work, and is how every DNSSEC implementation prevents the otherwise trivial downgrade attack. I do not believe there is any ambiguity in the wording of the BRs, but if there were, it would have been cleared up by the thread linked above. Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
