On Sat, 9 Sep 2017 18:10:02 -0700 Peter Bowen <[email protected]> wrote:
> On Sat, Sep 9, 2017 at 1:59 PM, Andrew Ayer <[email protected]> > wrote: > > On Sat, 9 Sep 2017 13:53:52 -0700 > > Peter Bowen via dev-security-policy > > <[email protected]> wrote: > > > >> On Sat, Sep 9, 2017 at 1:50 PM, Andrew Ayer <[email protected]> > >> wrote: > >> > > >> > 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/ > >> > >> Just as I received this, I finished testing with unbound, to see > >> what it does. See the results below. For your blackhole, > >> servfail, and refused cases it clearly says insecure, not bogus. > > > > That is very clearly against RFC4033, which says defines Insecure > > as: > > > > The validating resolver has a trust anchor, a chain > > trust, and, at some delegation point, signed proof of the > > non-existence of a DS record. This indicates that > > subsequent branches in the tree are provably insecure. A > > validating resolver may have a local policy to mark parts of the > > domain space as insecure. > > > > There is no "signed proof of the non-existence of a DS record" for > > blackhole, servfail, and refused, so it cannot possibly be insecure. > > I just found another tool that does checks and has a similar but > distinct response set: > > https://portfolio.sidnlabs.nl/check/expired.caatestsuite-dnssec.com/CAA > (bogus) > https://portfolio.sidnlabs.nl/check/missing.caatestsuite-dnssec.com/CAA > (bogus) > https://portfolio.sidnlabs.nl/check/blackhole.caatestsuite-dnssec.com/CAA > (error) > https://portfolio.sidnlabs.nl/check/servfail.caatestsuite-dnssec.com/CAA > (error) > https://portfolio.sidnlabs.nl/check/refused.caatestsuite-dnssec.com/CAA > (error) > https://portfolio.sidnlabs.nl/check/sigfail.verteiltesysteme.net/A > (bogus) > https://portfolio.sidnlabs.nl/check/bogus.d4a16n3.rootcanary.net/A > (insecure) https://portfolio.sidnlabs.nl/check/www.google.com/A > (insecure) > https://portfolio.sidnlabs.nl/check/www.dnssec-failed.org/A (bogus) According to https://portfolio.sidnlabs.nl/form this tool is just a web frontend for libunbound, so it suffers from the same libunbound bug (reported here: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439). > Given that there does not seem to be a consistent definition on how > "broken" DNSSEC should be handled, I think it is reasonable that CAs > should be given benefit of the doubt on the broken DNSSEC tests. I believe the following two facts are not disputed: 1. refused.caatestsuite-dnssec.com, servfail.caatestsuite-dnssec.com, and blackhole.caatestsuite-dnssec.com cause lookup failures. 2. The Baseline Requirements permit CAs to treat a lookup failure as permission to issue only when "the domain's zone does not have a DNSSEC validation chain to the ICANN root." What is disputed is whether these three domains' zones have a DNSSEC validation chain to the ICANN root. Considering the definition given in RFC 4033, incorporated by reference from RFC 6844, I say that they do, and that the CA is capable of determining this. What about these rules is so unclear it justifies giving CAs the benefit of the doubt for issuing for these three FQDNs? I do not believe the existence of a single DNS implementation that violates RFC 4033 and 4035 by neglecting to consider a response bogus in some situations is evidence of unclarity as to what constitutes a validation chain. Regards, Andrew _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
