Re: [Trans] text to address DKG's conspiring CAs attack

[David A. Cooper]

As others have pointed out, the description below is fundamentally flawed, and as a result the conclusion is flawed as well. See comments in-line below. On 03/14/2016 10:39 AM, Stephen Kent wrote: 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. What's effectively happening here is not that the two trust anchors are creating two intermediate (subordinate) CAs. They are creating a single intermediate (subordinate) CA, and each of them is issuing a cross-certificate to it.      +----------------+    +----------------+      | trust anchor 1 |    | trust anchor 2 |      +----------------+    +----------------+                 \              /                  \            /                +----------------+                | subordinate CA |                +----------------+ 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.) This is incorrect! X.509 requires name uniqueness, including across CA boundaries. [Since this issue isn't relevant to the "conspiring CAs attack," information about this inaccuracy is at the end of the email. 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. As noted by others, if the two (EE) certificates are identical, then there is only one EE certificate. So, in the scenario described above, there aren't two intermediate CAs and two (identical) EE certificates. There are two trust anchors, each issuing a certificate to a single subordinate CA, which in turn has issued a single EE certificate identifying the target Subject:      +----------------+    +----------------+      | trust anchor 1 |    | trust anchor 2 |      +----------------+    +----------------+                 \              /                  \            /                +----------------+                | subordinate CA |                +----------------+                        |                        |  EE certificate                        |               +------------------+               | targeted Subject |               +------------------+ 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.) Again, as others have noted, and as can be seen clearly in the figure above, from the relying party's point of view, there is only one intermediate CA. So, a browser checking a CRL or OCSP response will get the same result whether it is attempting to validate this EE certificate using trust anchor 1 or trust anchor 2 as the starting point for the certification path. There is nothing in a CRL or OCSP response that would make a CRL or OCSP response valid for a path that starts at trust anchor 1 but invalid for a path that starts at trust anchor 2. The only way I can see to (possibly) get the results described above would be if the "two" EE certificates had different values in the cRLDistributionPoints extension and/or the authorityInfoAccess extension so that the relying party would go to different sources for revocation information for the two EE certificates. But then, that would mean the two EE certificate weren't identical. 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. If there is an attack here, it seems that it would be as follows. Upon detection of the bogus certificate browsers determine that the subordinate CA is malicious and blacklist the cross-certificate from trust anchor 1 to subordinate CA, but don't blacklist any of the EE certificates issued by the subordinate CA (and the subordinate CA doesn't revoke them either). The browsers don't notice that there is a second cross-certificate for subordinate CA, from trust anchor 2, and so there continues to be a valid certification path for certificates issued by subordinate CA. ------------------------------------------------------------------ Unfortunately, there is some misinformation that X.509's name uniqueness requirement only applies to each CA. X.509 is very clear that this is not the case. Among other things, it says that "For every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users."  In addition, there is text in the Security Considerations section of RFC 6818 (RFC 5280 Clarifications) warning that there is a risk that two different CAs could issue certificates with the same subject name:      Among many other possible attacks, the attacker may issue bogus      certificates that have the same subject names as legitimate      certificates in order impersonate legitimate certificate subjects.      This could include bogus CA certificates in which the subject names      in the bogus certificates match the names under which legitimate CAs      issue certificates and CRLs.  This would allow the attacker to issue      bogus certificates and CRLs that have the same issuer names, and      possibly the same serial numbers, as certificates and CRLs issued by      legitimate CAs. You can also look at CMS (RFC 5652) to see that this is incorrect. It issues issuer name and serial number to identify a certificate:     The IssuerAndSerialNumber type identifies a certificate, and thereby     an entity and a public key, by the distinguished name of the     certificate issuer and an issuer-specific certificate serial number. This only works because the requirement for name uniqueness applies across all issuers, not individually to each CA. The indirect CRL mechanism in X.509 also requires on names being unique across CAs. So does the PKIX profile for attribute certificates (RFC 5755):    If an attribute certificate is tied to the holder's PKC using the    baseCertificateID component of the Holder field and the PKI in use    includes a rogue CA with the same issuer name specified in the    baseCertificateID component, this rogue CA could issue a PKC to a    malicious party, using the same issuer name and serial number as the    proper holder's PKC.  Then the malicious party could use this PKC in    conjunction with the AC.  This scenario SHOULD be avoided by properly    managing and configuring the PKI so that there cannot be two CAs with    the same name.  Another alternative is to tie ACs to PKCs using the    publicKeyCert type in the ObjectDigestInfo field.  Failing this, AC    verifiers have to establish (using other means) that the potential    collisions cannot actually occur, for example, the Certificate    Practice Statements (CPSs) of the CAs involved may make it clear that    no such name collisions can occur. Again, it notes that CA names have to be unique across the entire PKI, not just among those that have been issued certificates from a single CA.

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans