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
