On Sat, 9 Sep 2017 13:14:29 -0700 Peter Bowen via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> On Sat, Sep 9, 2017 at 11:50 AM, Andrew Ayer <a...@andrewayer.name> > wrote: > > 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. > > RFC 4033 refers to 4035 for the details on the protocol. In RFC 4035 > section 2.4, it says: > > A DS RR SHOULD point to a DNSKEY RR that is present in the child's > apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be > signed by the corresponding private key. DS RRs that fail to meet > these conditions are not useful for validation, but because the DS RR > and its corresponding DNSKEY RR are in different zones, and because > the > > Additionally both 4033 and 4035 state that there are four possible > statuses for DNSSEC: Secure, Insecure, Bogus, and Indeterminate. 4033 > notes the "signaling mechanism does not distinguish between > indeterminate and insecure states". In the examples I listed, the > resulting state is neither Secure nor Bogus. I'm not sure what point you are trying to make. Are you disputing that expired.caatestsuite-dnssec.com, missing.caatestsuite-dnssec.com, blackhole.caatestsuite-dnssec.com, and refused.caatestsuite-dnssec.com have validation chains to the root? They certainly meet the definition of bogus as defined in 4033, as there is a "secure delegation indicating that subsidiary data is signed" (the DS record), and the "response fails to validate for some reason". > > 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. > > Not every DNSSEC implementation gives the result you claim. I usually > use drill (which is part of the unbound/nsd/ldns/getdns family) to > test. Here is the output for one of your cases: drill is buggy and insecure. Obviously, such implementations can be found. Note that drill is just a "debugging/query" tool, not a resolver you would actually use in production. You'll find that the production-grade resolver from that family (unbound) correctly reports an error when you try to query the CAA record for refused.caatestsuite-dnssec.com: https://unboundtest.com/ Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
