On Sat, 9 Sep 2017 06:57:39 -0400 Jonathan Rudenberg via dev-security-policy <[email protected]> wrote:
> > > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy > > <[email protected]> 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. As I explained in my reply to Peter, it's not "valid DNSSEC chain", but rather a "validation chain", which is defined by RFC4033, albeit under the synonymous term "authentication chain". > 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. The BRs could arguably be interpreted to not require DNSSEC validation during lookups, although as I explained in my reply to Jeremy I do not find this to be a very compelling interpretation. However, it is not at all ambiguous that a request must be denied if the lookup fails for non-DNSSEC reasons, if there is DNSSEC validation chain to the ICANN root. Given the reference to RFC4033 from RFC6844 in the definition of DNSSEC, CAs should be able to figure out what this means. Therefore, the blackhole and refused certs are unquestionably misissuances, if not also missing and expired. Regards, Andrew _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
