Below is the text I plan to insert as a new section in the threat
analysis doc,
to address the attack DKG articulated. Comments welcome.
Steve
------
3.3 Malicious, Colluding CAs
Section 3.2 examined attacks in which a single CA issued a bogus
certificate. Daniel Kahn Gilmor posited an attack in which two or more
CAs might collude to issue a bogus certificate in a fashion designed to
foil the safeguards envisioned by CT. Specifically, he suggested that
two trust anchors could create intermediate (subordinate) CAs that have
the same Subject name, the same public key, and the same Subject Key
Identifier) in the their certificates.In fact, an attack of the sort
Gilmor envisioned can be mounted by any two CAs that are not
name-constrained; the attack need not be initiated by trust anchors per
se. (Also note that X.509 and RFC 5280 do not preclude creation of
doppelganger CAs; the requirement for Subject name uniqueness applies
individually to each CA but not across CA boundaries, and there is no
requirement for public key uniqueness across CAs.)
The attack requires that both of the doppelganger CAs issue a
certificate for a targeted Subject (e.g., web site). These two (EE)
certificates are identical; they contain the same name, public key,
serial number, etc. Only one of the malicious CAs logs a bogus
certificate and acquires an SCT for it. Because the bogus certificates
are identical, the SCT will match both.
The logged bogus certificate can be detected by a Monitor (third party
or self), that is watching the log(s) to which the certificate was
posted. Thus the detection aspect of CT still works with regard to this
certificate. When this certificate is detected, the CA that logged the
certificate may revoke it, i.e., place it on a CRL or create an OCSP
response for it. However, a browser checking a CRL or OCSP response will
not match this revocationstatus data against the other, not-logged bogus
certificate. (This is because revocation status checking is performed in
the context of a certificate path and the two bogus certificates have
different certificate paths.) Revoking a detected, bogus certificatemay
be the best strategy for the malicious CAs. It makes issuance of the
bogus certificate appear to be an accident, and thus browser vendors may
not feel the need to make an entry on their blacklists for the bogus
certificate or the CA that issued it.
If the CA that issued the (logged) bogus certificate fails to revoke it,
browser vendors might blacklist the certificate. However, as noted
above, the other bogus certificate, which was not logged, still will
match the SCT created for the logged (now revoked) certificate. If
remediation is effected by blacklisting (instead of revocation by the
malicious CA) then the ability of CT to deal with this sort of attack
may be diminished. Some forms of blacklisting will cause the not-logged
bogus certificate to be detected and rejected, while others will not,
depending on the details of the blacklisting mechanism. Mechanisms for
blacklisting by browsers are not specified in any IETF standards. The
mechanisms are browser-specific, and the choice of how to blacklist
(e.g., the bogus certificate vs. the CA that issued it) are the purview
of each browser vendor. Thus, depending on the details of the blacklist
mechanism and the way that a browser vendor chooses to manage this list,
a doppelganger CA attack might or might not pose a problem in terms of
successful remediation of the attack.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
