> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy > <[email protected]> wrote: > > On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy < > [email protected]> wrote: > >> >>> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy < >> [email protected]> wrote: >>> >>> That seems like very poor logic and justification. >>> >>> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for >>> literally years now, perhaps it's worth asking why CAs are only now >>> discovering issues. That is, is the only reason we're discovering issues >>> because CAs waited for the last possible moment? If so, why. >> >> I think the BR clause that brings DNSSEC in is poorly drafted. > > > Why?
As written, it’s not clear what the point is, as I describe below. If the intent was to require DNSSEC validation, it should say that clearly. >> Additionally, it may be a stretch to say that DNSSEC in the context of CAA >> has been discussed extensively. > > > I'm not sure I understand why you feel some special discussion is or was > necessary, given the discussion that occurred in IETF on this. That is, are > you asserting that these issues - such as CAs not even checking CAA - are > because of the ballot language? I’m only talking about the DNSSEC-related issues here, I’m not aware of any CAs that are not or were not checking CAA due to DNSSEC. Some CAs have interpreted this clause to not require DNSSEC validation when doing CAA queries, do you believe that interpretation is valid? My interpretation is that DNSSEC validation is required to the point to the domain’s zone (but not to the CAA record set itself) if a CA wants to treat a record lookup failure as permission to issue. If the goal is to address the relevant security considerations in RFC 6844 with DNSSEC, this appears to leave a pretty gaping hole where a CA could: 1) not implement DNSSEC at all, and treat lookup failures as issuance-blocking errors; or 2) implement enough DNSSEC to decide if a zone has a “validation chain” without ever validating the CAA queries themselves Thus, the clause as I interpret it only prevents a specific attack that drops CAA query answers and doesn't provide any authenticity or integrity guarantees. Instead of dropping an answer, an attacker could just replace the answer with one that they want. > I’m not familiar with relevant discussions that are not indexed by Google, >> but when I researched this I only found a few exchanges about this specific >> requirement on the public mailing list. > > > This was discussed at nearly every single F2F since late 2013/early 2014. > The DNSSEC discussion was very much part of the IETF discussions. > > What discussions do you feel should have happened, but didn’t? So far I’ve been working of the interpretation above, and so I’ve been trying to understand why DNSSEC is brought in while not addressing any meaningful security considerations. >>> I think arguments that suggest that failing to do the right thing makes >> it >>> OK to do the wrong thing are the worst arguments to make :) >> >> My argument is not that it’s okay to do the wrong thing. Instead, I think >> it’s worth evaluating the DNSSEC requirement to decide whether it should >> continue to be defined as "the right thing” in the BRs. I did not see any >> such analysis on cabfpub. > > > I'm surprised to even see the suggestion that it isn't. Do you feel the > security considerations are insufficiently documented in the CAA RFC? Do > you feel it's not sufficiently obvious the risks of not using DNSSEC? The security considerations are clear, and if properly implemented, DNSSEC would help there. These security considerations also apply to all online domain validation methods, and DNSSEC isn’t required there, so I’m not yet convinced by this argument. What isn’t clear is whether DNSSEC should be deployed at all. There have been many large outages caused by DNSSEC[0], the tooling is horrible, weak crypto is rampant throughout the system, and the specification is extraordinarily complex. The footgun potential is greater than HPKP in scale, and the end result is something that even if deployed widely won’t even protect the average user from spoofed DNS answers on open WiFi. So, no, I’m not convinced that it’s the right thing. Jonathan [0] https://ianix.com/pub/dnssec-outages.html _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
