Hey Tim, The issue was a call between the CA and CAA checker. The CAA checker would check the DNS and verify the DNSSEC chain. However, when retrieving the information from the CAA checker, the CA had the error, which means the CAA check was not evaluated correctly. Under normal operation the CAA check does the DNSSEC , CAA, and other DNS queries. Here it wasn't a DNS failure - it was a communication failure between the CA and CAA checker.
I guess you could say there were two failures in this case. First that the CAA check timed out internally and second that the DNSSEC check never happened. The mis-issuance still amounts to the same thing. Normally, even if we get a DNS failure, we can usually check to see if the zone is signed (at least at the root zone). If there is a signed root zone, then we treat the entire zone as signed (meaning we fail on error). Jeremy -----Original Message----- From: Tim Shirley <tshir...@trustwave.com> Sent: Friday, May 10, 2019 7:30 AM To: Jeremy Rowley <jeremy.row...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CAA record checking issue Jeremy, Thanks for sharing this. After reading your description, I'm curious how your system was previously (or is now) satisfying the third criteria needed to issue in the face of a record lookup failure: confirming that the domain's zone does not have a DNSSEC validation chain to the ICANN root. Wouldn't any issuance require at least one successful DNS query in order to confirm the lack of a DS record somewhere between the TLD and the domain you're checking so you know the domain doesn't have a valid DNSSEC chain? If the CAA checking service was down, wouldn't those have all timed out? Or are those checks being done from a different system that wasn't down? Regards, Tim On 5/9/19, 10:05 PM, "dev-security-policy on behalf of Jeremy Rowley via dev-security-policy" <dev-security-policy-boun...@lists.mozilla.org on behalf of dev-security-policy@lists.mozilla.org> wrote: FYI, we posted this today: https://scanmail.trustwave.com/?c=4062&d=99zU3MWO5ZnJnVq-TZZut0-4BjNGA3S27plK9QDITw&s=5&u=https%3a%2f%2fbugzilla%2emozilla%2eorg%2fshow%5fbug%2ecgi%3fid%3d1550645 Basically we discovered an issue with our CAA record checking system. If the system timed out, we would treat the failure as a DNS failure instead of an internal failure. Per the BRs Section 3.2.2: "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" The failure was not outside our infrastructure so issuance was improper. We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a new cert today. What we are proposing is to revoke these certificates and reissue them (if they pass all the proper checks). The rest would pass if we issued today so we were going to leave these where they are while disclosing them to the Mozilla community. Other suggestions are welcome. The issue was put into the code back when CAA record checking became mandatory (Sept 2017). We generally have a peer review of our code so that at least one other developer has looked at the system before release. In this case, neither PM nor a second reviewer was involved in the development. We've since implemented more stringent development processes, including ensuring a PM reviews and brings questions about projects to the compliance team. Anyway, let me know what questions, comments, etc you have. Thanks! 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