For reference, here is the relevant bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398428
> On Sep 9, 2017, at 05:21, Jeremy Rowley via dev-security-policy > <[email protected]> wrote: > > big.basic.caatestsuite.com > > [JR] We only check CAA records with UDP to keep performance good on certs > with hundreds of SANs. I couldn't find a requirement that mandates use of > TCP to check CAA records. Should TCP be required? Not using TCP is fine. However, if the TC (truncation) bit is set (as it is in this case), you cannot know if you’ve received the complete CAA record set and must refuse to issue. > refused.caatestsuite-dnssec.com > > [DC] This will always issue. A refusal is treated as a failure. Under the > BRs a failure is permission to issue if we retry and DNSSec is not present. > However, although DNSSec is present on the test suite's side, we can't see > it. Therefore, we get refused (a lookup failure), retry (resulting in > another lookup failure), followed by a DNSSec check (which fails because > retrieving the RSSIG record is refused). There's no path under which this > won't issue because we can't see whether DNSSec is present. It sounds like your DNSSEC implementation is incorrect. To do the lookup properly, you’d walk down from the root zone doing DNSSEC validation and find that the lookup state is ‘Bogus’ due to the refused DNSKEY query. Here’s a graphic that shows this: http://dnsviz.net/d/refused.caatestsuite-dnssec.com/dnssec/ > missing.caatestsuite-dnssec.com > > [DC] I believe this is properly issued. We retrieved the DNS record (no > failure) and found no CAA record present. The relevant portion of the BRs > state: "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." Although there is a valid DNSSEC chain > to the root, issuance is still permitted because there was no lookup > failure. The DNSSEC lookup state is Bogus here too, because there is no valid RRSIG record. There is a lookup failure when using a properly implemented client. http://dnsviz.net/d/missing.caatestsuite-dnssec.com/dnssec/ https://dns.google.com/query?name=missing.caatestsuite-dnssec.com&type=CAA&dnssec=true > expired.caatestsuite-dnssec.com > > [DC] As with 4, I believe this is properly issued. We retrieved the DNS > record (no failure). The DNS lacked a CAA record. Although there is a valid > DNSSEC chain to the root, issuance is still permitted because there was no > lookup failure. Again, the lookup state is Bogus, due to the expired RRSIG. This should result in a lookup failure. http://dnsviz.net/d/expired.caatestsuite-dnssec.com/dnssec/ https://dns.google.com/query?name=expired.caatestsuite-dnssec.com&type=CAA&dnssec=true > blackhole.caatestsuite-dnssec.com > > [DC] Retrieval of the RSSIG record is failing, which we interpreted as the > lack of DNSSec. If the DNSSec check times out, we issue because 1) The DNS > lookup failed, 2) we retried the DNS lookup and it failed again, and 3) > DNSSec is absent (because the RSSIG record lookup failed). The eTLD+1 has a DNSSEC validation chain to the ICANN root, so it is not absent. http://dnsviz.net/d/blackhole.caatestsuite-dnssec.com/dnssec/ _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
