Re: [Trans] revised threat analysis doc

[David A. Cooper]

Is it necessary for me to point out that this draft has not fixed the problems from the previous drafts? Isn't this supposed to be a working group document? Why does the document still talk about two different CAs that have the same name and same key, and that are "both" controlled by the same entity (the attacker)? This insistence on referring to this CA as "two CAs" is not only factually wrong (as are the statements about RFC 5280), they lead to confusion. The text suggests that the two or more CAs that might collude to issue a bogus certificate are the "two CAs" that "have the same Subject name and the same public key," but it is not. The two colluding CAs are the two CAs that each issue a cross-certificate to the one (bogus) CA that issues the (bogus) EE certificate. Granted, "colluding" may not be the appropriate term. They may be two CAs that have been unknowingly compromised by the attacker into issuing the cross-certificates to the (bogus) CA controlled by the attacker. But what makes this attack different is the two cross-certificates; so if there is any collusion, it is between the issuers of the cross-certificates. On 04/14/2016 09:55 AM, Stephen Kent wrote: We've been having trouble getting the -05 version of the threat analysis posted, so my message about the changes that have been incorporated is a bit premature. Here is the modified text: 3.3 Malicious, Colluding CAs Section 3.2 examined attacks in which a single CA might issue a bogus certificate. There is also the potential that two or more CAs might collude to issue a bogus certificate in a fashion designed to foil the remediation (but not detection) safeguards envisioned by CT. Their goal would be trick a CT-aware browser into accepting a bogus certificate because it was accompanied by a valid SCT, while evading certificate revocation status indications. This section explores such scenarios. In this attack two CAs that do not share a common path to a trust anchor, collude to create a “doppelganger” (bogus) EE certificate. The attack need not be initiated by trust anchors; any subordinate pair of (not name-constrained) CAs can effect this attack without the knowledge of superiors CAs (which are presumed to be benign). The two CAs must have the same Subject name and the same public key for the attack. (RFC 5280 doe not explicitly preclude the creation of two CAs with the same name, so long as the parent CAs are distinct. Requirements for Subject name uniqueness apply individually to each CA but not across CA boundaries, as per Section 4.2.1.6. However, the Security Considerations section of RFC 5280 warns that name collisions could cause security problems.) Because the two CAs have the same name and make use of the same key, each can issue the (bogus) doppelganger certificates. One of the CAs would log the certificate and acquire an SCT for it, while the other would not. Because the bogus certificate is logged, it is subject to detection as such by a Monitor. Once the bogus certificate is detected it is anticipated that action will be taken to render it invalid. The bogus certificate itself might be revoked by the CA that issued and logged it, an action that masks the malicious intent of that CA. A browser vendor might add the bogus certificate to a blacklist maintained by the vendor, e.g., because the CA failed to revoke the bogus certificate. If the CA that logged the bogus certificate is suspected of being malicious, e.g., because it has a history of using bogus certificates, the certificate of that CA might itself be revoked. This revocation might be effected by the parent of that CA (which is not complicit), or by a browser vendor using a blacklist. Whether the proposed attack can achieve its goal depends on which revocation mechanism is employed, and which certificate or certificates are revoked. 3.3.1 Revocation of the Bogus Certificate If the bogus (EE) certificate is revoked by the CA that issued and logged it, browsers should treat that certificate as invalid. However, a browser checking a CRL or OCSP response might not match this revocation status data against the doppelganger issued by the second CA. This is because revocation status checking is performed in the context of a certification path (during path validation). The doppelgangers have different certification paths and thus the revocation status data for each might be acquired and managed independently. (RFC 5280 does not provide implementation guidance for management of revocation data. It is known that some relying party implementations maintain such information on a per-certificate path basis, but others might not.) Even if the bogus certificates contain an AIA extension pointing to an OCSP server the attack might still succeed. (As noted in the Section 1, RFC 5280 does not mandate inclusion this extension, but its presence is required by CABF requirements.)  As noted in Section 3.2.1.1.1, a malicious CA could send a “good” OCSP response to a targeted browser instance, even if other parties are provided with a “revoked” response. Also note that a TLS server can supply an OCSP response to a browser as part of the TLS handshake [RFC6961], if requested by the browser. A TLS server posing as the entity named in the bogus certificate could acquire a “good” OCSP response from the colluding CAs to effect the attack. Only if the browser relies upon a trusted, third-party OCSP responder, one not part of the collusion, would the attack fail. The analysis above also applies to the use of CRLs to disseminate certificate revocation status data. The doppelganger certificate could contain a CRL distribution point extension instead of an AIA extension. In that case a site supplying CRLs for the colluding CAs could supply different CRLs to different requestors, in an attempt to hide the revocation status of the doppelganger from targeted browsers instances. This is analogous to a split-view attack effected by a CT log. However, as noted in Section 3.2.1.1 and 3.2.1.1.1, no element of CT is responsible for detecting inconsistent reporting of certificate revocation status data. (Monitoring in the CT context tracks log entries made by CAs or Subjects. Auditing is designed to detect misbehavior by logs, not by CAs per se.) If the CA that logged the certificate does not revoke it, a browser vendor might enter the bogus certificate into a “blacklist”. Unfortunately, there are no IETF standards for such blacklists. Thus it is conceivable that the revocation status data also might be managed in a path-specific fashion. If that were true, then the attack could succeed. However, if a vendor maintains revocation status data in a path-independent fashion, then the attack will fail. For example, if revoked certificates are identified by CA name and serial number, or a hash of the certificate, this attack would fail. 3.2.2 Revocation of the Colluding CA Certificate If the CA that logged the bogus certificate is viewed as acting maliciously, its parent might revoke that CA’s certificate. Even though the two colluding CAs have the same name and use the same public key, their certificates are distinct, e.g., they were issued by different parents and almost certainly have different certificate serial numbers. Thus revocation of the certificate of the CA that logged the bogus certificate does not affect the certificate of its colluding partner. In this case, the bogus EE certificate would be treated as valid when it appears in a certification path involving the second colluding CA. Thus revocation the certificate for the CA that was detected as malicious does not prevent this attack from succeeding. A vendor also might choose to add the certificate of the CA that issued the bogus certificate to its blacklist, e.g., if that CA refuses to revoke the bogus certificate. This also may not prevent the bogus certificate from being accepted by a browser. For example, if the CA certificate blacklist entry is analogous to a CRL entry (Subject name of the parent of the malicious CA and the serial number of the malicious CA’s certificate), the colluding CA’s certificate would still be valid in this case.

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