Hi everyone,
We received a certificate problem report at 11 pm on Sep 8, 2017 from Andrew Ayer alleging the mis-issuance of 6 certificates because of a failure to properly verify CAA records. I'm sharing the report here because there are questions about CAA record checking that we feel are better shared with the broader community. We're looking for clarification on whether these are a) mis-issuances based on a misunderstanding of the requirement, b) an issue with the test suite used to verify CAA compliance, or c) gaps in the RFC/BRs. The report: [DigiCert] issued the following certificates in violation of the Baseline Requirements' CAA checking requirement: 1. https://crt.sh/?sha256=26F4FFABCF94AA16A85C7F02D9F4604E74A41ACE51DA1C55B732E 1618798D04A 2. https://crt.sh/?sha256=2619EAA800BA627CC3C1971DF0BB8006B2831B500935E94379952 4E81CA3EDAB 3. https://crt.sh/?sha256=D0DA8826B05D5A079E4356D4FED6300A94B0E2B9E6E40FCB6AAEA C1F2163AF2E 4. https://crt.sh/?sha256=300D20D0E63112AD77D09BBA8F02E9B075E265DF21E0FE6F18C38 CD11179D43B 5. https://crt.sh/?sha256=CC08B270A8BF66D431E9AC073C7014373F6CE582F1CF5C08CF73C 340F91327FB 6. https://crt.sh/?sha256=A3AA9FDC0ED72C29C969E76A929F517EB093A574ED2C248CBAFC7 85767403FC6 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? 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. 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. 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. 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. 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). Thoughts? Jeremy
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
