On Sat, 9 Sep 2017 09:21:30 +0000 Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> Certificate 1 contains a single DNS identifier for > big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> . > This DNS name has a CAA resource record set that is too large to fit > within a single DNS UDP packet, but small enough to fit within a DNS > TCP packet. The only CAA record containing an issue property is: > > big.basic.caatestsuite.com <http://big.basic.caatestsuite.com> . > IN CAA 0 issue "caatestsuite.com <http://caatestsuite.com> " > > Therefore, only caatestsuite.com <http://caatestsuite.com> is > allowed to issue for this identifier. > > > > [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? Jonathan Rudenberg has already addressed this point. > Certificate 2 contains a single DNS identifier for > cname-deny-sub.basic.caatestsuite.com > <http://cname-deny-sub.basic.caatestsuite.com> . The following DNS > records are > > relevant: > > cname-deny-sub.basic.caatestsuite.com > <http://cname-deny-sub.basic.caatestsuite.com> . IN CNAME > sub.deny.basic.caatestsuite.com > <http://sub.deny.basic.caatestsuite.com> . > > deny.basic.caatestsuite.com <http://deny.basic.caatestsuite.com> . IN > CAA 0 issue "caatestsuite.com <http://caatestsuite.com> " > > There is no CAA record at sub.deny.basic.caatestsuite.com > <http://sub.deny.basic.caatestsuite.com> . According to RFC 6844, > the only CA allowed to issue for cname-deny-sub.basic.caatestsuite.com > <http://cname-deny-sub.basic.caatestsuite.com> > > is caatestsuite.com <http://caatestsuite.com> . > > > > [DC] I don't read the RFC this way. I know both the CAB Forum and > IETF hotly debated CNAME's interplay with CAA a couple of times, but > I thought we were awaiting on adoption of the Errata to determine the > proper resolution. My interpretation of the RFC remains that the CA > verifies X.Y.Z, then the alias of X.Y.Z, then Y.Z, then alias of > Y.Z, etc. If A.B.C. is the alias of X.Y.Z, you'd only verify the CAA > record at A.B.C., not A.B.C. followed by B.C. followed by C. This is > perhaps clarified in the RFC errata, but that is not official yet > and not part of the BR requirement. I don't think there's sufficient > clarity around the correct CAA-CNAME process to implement a code > change. The algorithm specified in section 4 of RFC 6844 clearly supports my interpretation, although the examples support your interpretation. Erratum 5065 changes the algorithm to match the examples, but this erratum has not been incorporated into the BRs yet. I believe that the algorithm specification carries more normative force than the examples and should therefore take precedence, making this a misissuance. That said, I don't think it would be unreasonable for Mozilla to excuse the misissuance and not require CAs to implement code changes, at least until the incorporation of Erratum 5065 is resolved. > Certificate 3 contains a single DNS identifier for > refused.caatestsuite-dnssec.com > <http://refused.caatestsuite-dnssec.com> . Attempts to query the CAA > record for this DNS name result in a REFUSED DNS response. Since > there is a DNSSEC validation chain from this zone to the ICANN root, > CAs are not permitted to treat the lookup failure as permission to > issue. > > > > [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. You determine whether DNSSEC is present by looking in the parent zone for the DS record, as I explained in detail in my reply to Peter Bowen. Incidentally, Kirk Hall from Entrust posed this exact scenario (DNS server returning REFUSED) to cabfpub on August 2: https://cabforum.org/pipermail/public/2017-August/011800.html In the ensuing thread Phillip Hallam-Baker and Ryan Sleevi both confirmed that the CA must reject the request, and explained why failing to do so would open up a downgrade attack. > Certificate 4 contains a single DNS identifier for > missing.caatestsuite-dnssec.com > <http://missing.caatestsuite-dnssec.com> . This DNS name has no CAA > records, but the zone is missing RRSIG records. Since there is a > DNSSEC validation chain from this zone to the ICANN root, the DNS > lookup should fail and this failure cannot be treated by the CA as > permission to issue. > > > > [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. It is true the BRs do not explicitly require DNSSEC validation during the lookup process, and if a CA is not validating DNSSEC during the lookup, then there would be no lookup failure. However, I would argue that the requirement to do DNSSEC validation is implied by the requirement to check for a "DNSSEC validation chain to the ICANN root" should a lookup fail. Failure to validate DNSSEC during the lookup would remove all security value from the requirement to check for a DNSSEC validation chain should a lookup fail. I find it rather unfortunate that any CA would choose to interpret the BRs this way, especially in light of the above thread which underscored the need to prevent downgrade attacks. > Certificate 5 contains a single DNS identifier for > expired.caatestsuite-dnssec.com > <http://expired.caatestsuite-dnssec.com> . This DNS name has no CAA > records, but the zone contains expired RRSIG records. Since there is > a DNSSEC validation chain from this zone to the ICANN root, the DNS > lookup should fail and this failure cannot be treated by the CA as > permission to issue. > > > > [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. See response to certificate 4. > Certificate 6 contains a single DNS identifier for > blackhole.caatestsuite-dnssec.com > <http://blackhole.caatestsuite-dnssec.com> . All DNS requests for > this DNS name will be dropped, causing a lookup failure. Since there > is a DNSSEC validation chain from this zone to the ICANN root, CAs > are not permitted to treat the lookup failure as permission to issue. > > > > [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). As with the REFUSED test, this should have been rejected because you know from the DS record in the parent zone that there is a DNSSEC validation chain to the root. Regards, Andrew _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
