Not saying we implemented DNSSEC checking correctly, but I don't think the requirements are as clear as you present them.
The BRs state that: " CAs are permitted to treat a record lookup failure as permission to issue if: • the failure is outside the CA's infrastructure; • the lookup has been retried at least once; and • the domain's zone does not have a DNSSEC validation chain to the ICANN root." That's the entire corpus of information related to DNSSEC in the BRs. Under 4 and 5, we successfully returned a DNS record. The lookup didn’t fail so the sentence "the domain's zone does not have a DNSSEC validation chain to the ICANN root" doesn't apply. There is no need to check the DNSSEC validation chain in this case. For 3 and 6: RFC 4033: 1) Is not referenced in the BRs 2) Does not define domain's zone 3) Does not reference a "validation chain" (but does define authentication chain as you noted) 4) Does not mention an ICANN root 5) Is only a footnote in RFC 6844 Although most of these are straight forward without being defined, the culmination of semi-loose specifications makes for one very loose specification at the CAB Forum level, especially where programs like drill apparently did DNSSEC checking wrong. Of course, we would like to properly check DNSSEC (or at least check it more properly) so I'm interested to hear your opinion on whether this works as a fix: 1) Checking the entire DNSSEC chain was incredibly slow, causing the certs to take 10 sec plus to issue. We figured checking RRSIG removed this delay by simply checking whether DNSSEC exists. If DNSSEC exists and we failed to return a DNS record, we'll just block the cert. 2) Instead of checking the DNSSEC chain, could we simply check the DNSKEY RR at the parent? If the DNS RRSet exists at the parent, we will simply refuse the cert issuance. This way we avoid the super long issuance times while still respecting DNSSEC requirements. Thanks a ton for the discussion on this. Jeremy -----Original Message----- From: Andrew Ayer [mailto:a...@andrewayer.name] Sent: Saturday, September 9, 2017 1:01 PM To: Jonathan Rudenberg <jonat...@titanous.com> Cc: Jonathan Rudenberg via dev-security-policy <dev-security-policy@lists.mozilla.org>; Peter Bowen <pzbo...@gmail.com>; mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: CAA Certificate Problem Report On Sat, 9 Sep 2017 06:57:39 -0400 Jonathan Rudenberg via dev-security-policy <dev-security-policy@lists.mozilla.org> 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. 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
