Looks good. Clever attack; dkg has a twisted mind ☺ Do we generally credit individuals in docs?
-- Senior Architect, Akamai Technologies IM: [email protected] Twitter: RichSalz From: Stephen Kent [mailto:[email protected]] Sent: Monday, March 14, 2016 10:40 AM To: [email protected] Subject: [Trans] text to address DKG's conspiring CAs attack 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 revocation status 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 certificate may 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
