Hi Stephen, Finally catching up on the latest version of your new threat analysis text...
On Apr 14, 2016, at 3:55 PM, Stephen Kent <[email protected]> wrote: > 3.2.1.1.1. Self-monitoring Subject > > > > < add a second paragraph> > > > > A malicious CA might revoke a bogus certificate to avoid having browser > vendors take punitive action against the CA and/or to persuade them to not > enter the bogus certificate on a vendor-maintained blacklist. However, the > CA > might provide a “good” OCSP response (from a server it operates) to a > targeted > user (browser instance) as a way to circumvent the remediation nominally > offered > by revocation. No component of CT is tasked with detecting this sort of > misbehavior > by a CA. (The misbehavior is analogous to a log offering split views to > different > clients. The Audit element of CT is tasked with detecting this sort of > attack.) > Just a nitpick: in the parenthetical about “analogous to a log offering split view", may be worth adding a forward-reference to the text below (or just the words “described below”) containing the detailed discussion of that class of attack? > 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. I agree with David Cooper that describing this as “two CAs” is rather strange given the assumption that they have “the same Subject name and public key”. I would call that “One Malicious CA with Two Certificate Chains” or something like that. > 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. The above next never explicitly describes what the actual relevant attack is, or why exactly “two trust anchors” make the attack back bad and can foil the remediation procedures. It almost does, but not quite. It needs to say something like, “The CA that logged the bogus certificate may get detected and the certificate revoked via that trust anchor, but the same certificate remains usable and un-revoked via the other trust anchor through which the bogus certificate was not logged or revoked.” Or something like that. I guess the text in 3.3.1 does get to discussing this “main point", but only after the reader has waded through the several paragraphs above, without having (yet) been made aware of the whole reason for existence of this whole section. It’s probably best to summarize the attack/implications (and perhaps forward-reference the extended discussion below) in one quick sentence toward the beginning of 3.3. > 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.) > > […] > > ------- > > 3.4 Undetected Compromise of CAs or Logs > > Sections 3.1 and 3.2 examined attacks in the context of non-malicious and > malicious CAs, and benign and misbehaving logs. Another class of attacks > might occur in the context of a non-malicious CA and/or a benign log. > Specifically these CT elements might be compromised and the compromise might > go undetected. Compromise of CAs and logs was noted in Section 2, as was > coercion of a CA. As noted there, a compromised CA is essentially a malicious > CA, and thus the discussions in Section 3.2 are applicable. The case of an > undetected compromise warrants some additional discussion, since some relying > parties may see signed objects issued by the legitimate (non-malicious) CA, > others may see signed objects from its compromised counterpart, and some may > see objects from both. In the case of a compromised CA or log the adversary > is presumed to have access to the private key used by a CA to sign > certificates, or used by a log to sign SCTs and STHs. Because the compromise > is undetected, there will be no effort by a CA to have its certificate > revoked or by a log to shut down the log. > > > 3.4.1 Compromised CA, Benign Log > > In the case of a compromised (non-malicious) CA, an attacker uses the > purloined private key to generate a bogus certificate (that the compromised > CA would not issue). If this certificate is submitted to a (benign) log, then > it subject to detection by a Monitor, as discussed in 3.1.1.1. If the bogus > certificate is submitted to a misbehaving log, then an SCT can be generated, > but there will be no entry for it, as discussed in 3.1.1.2. If the bogus > certificate is not logged, then there will be no SCT, and the implications > are as described in 3.1.2. > > This sort of attack may be most effective if the CA that is the victim of the > attack has issued a certificate for the targeted Subject. In this case the > bogus certificate will then have the same certification path as the > legitimate certificate, which may help hide the bogus certificate. However, > means of remedying the attack are independent of this aspect, i.e., > revocation can be effected irrespective of whether the targeted Subject > received its certificate from the compromised CA. > > A compromised (non-malicious) CA may be able to revoke the bogus certificate > if it is detected by a Monitor, and the targeted Subject has been notified. > It can do so only when the serial number of the bogus certificate is made > known to this CA. Also, the bogus certificate cannot have been issued with > an Authority Information Access (AIA) or CRL Distribution Point (CRL DP) > extension that enables only the malicious twin to revoke the certificate. > (The AIA extension in the bogus certificate could be used to direct relying > parties to an OCSP server controlled by the malicious twin. The CRL DP > extension could be used to direct relying parties to a CRL controlled by the > malicious twin.) If the bogus certificate contains either extension, the > compromised CA cannot effectively revoke it, but it will also be apparent > that the bogus certificate It’s probably worth clarifying exactly how this is “apparent” and to whom. e.g., something like, “also be apparent to anyone who checks the certificate against the uncompromised log and finds the SCT missing”, assuming that’s what you had in mind. Inferable, but just best to be explicit. > was issued by the malicious twin. (The AIA or CRL DP extension would provide > a strong indication that the bogus certificate was not generated by the > compromised CA itself.) > > If the serial number of the bogus certificate is the same as for a valid, > not-expired certificate issued by the CA (to the target or to another > Subject), then revocation poses a problem. This is because revocation of the > bogus nitpick: extra space between “revocation” and “poses" > certificate will also invalidate a legitimate certificate. This problem may > cause the compromised CA to delay revocation, thus allowing the bogus > certificate to remain a danger for a longer time. Wait - isn’t the basic assumption of this section that the CA’s private key has been stolen? And in that case, shouldn’t the CA’s public key itself be revoked and considered untrustworthy, together with any certificate the CA has signed in the past (or signs in the future) with that key? It seems like even if there is a “legitimate certificate” that was signed by the same key, it should get revoked too! If that’s not the case, then the “why” needs to be clarified in the above paragraph, and it needs to be stated in what situations a relying party may still deem the “legitimate certificate” trustworthy despite being signed by a compromised CA key. > 3.4.2 Benign CA, Compromised Log > > A benign CA does not issue bogus certificates, except as a result of an > accident or attack. So, in normal operation, it is not clear what behavior by > a compromised log would yield an attack. If a bogus certificate is issued by > a benign CA (under these circumstances) is submitted to a compromised > (non-malicious) log, then both an SCT and a log entry will be created. Again, > it is not clear what additional adverse actions the compromised log would > perform to further an attack on CT. Although not quite as worrisome as other attacks in practice, there is a DoS/censorship attack opportunity through equivocation here that might be worth mentioning. In particular, the compromised log could provide an SCT for a legitimate cert, and include the cert in a version of the log it shows most people, but then the compromised log server (or an evil twin of it) could send targeted relying parties a different log history that doesn’t include the legitimate cert. As a result, a web browser run by a targeted user will find the cert missing from the log and inform the user that the web site may be insecure/compromised, thus making the user (falsely) think the web site is broken rather than the log server. Of course, if the targeted user’s web browser can and does gossip STHs with benign CT servers, the discrepancy between the log server’s two histories will be detectable, and it will become known that the log server is compromised. However, if the user’s web browser is unable to gossip STHs with benign CT servers (e.g., because the only trusted auditor(s) are blocked), or if the browser is unwilling to gossip STHs for privacy reasons, or just doesn’t want the state/storage costs of tracking and gossiping all log-servers’ STH histories, then the attack might go undetected and the user might persistently think the web site itself is compromised or just broken. This might actually be a behavior desired by the attacker (effectively block the website but make the user think it’s the website’s fault) in some state-censorship type scenarios. > 3.4.3 Compromised CA, Compromised Log > > As noted in 3.4.1, an evil twin CA may issue a bogus certificate that > contains the same Subject name as a legitimate certificate issued by the > compromised CA. Alternatively, the bogus certificate may contain a different > name but reuse a serial number from a valid, not revoked certificate issued > by that CA. > > The evil twin CA might submit a bogus certificate to the evil twin of a > compromised log. The operator of the evil I would make it explicit here that the “evil twin CA” and the “evil twin of a compromised log” are very likely to be one and the same, i.e., just the attacker himself. Perhaps just “…of a compromised log (which may be the same attacker)." > twin log can use the purloined private key to generate SCTs for certificates > that have not been logged by its legitimate counterpart. These SCTs will > appear valid relative to the public key associated with the legitimate log. > However, an STH issued by the legitimate log will not correspond to a tree > containing these SCTs. Thus thorough checking of the SCTs issued by the evil > twin log will identify this discrepancy. "Thorough checking" by whom, against what reference point? Here it is important to bring out the question (again) of whether the relying party or parties targeted with this attack can, or do, gossip with uncompromised CT entities in order to be able to do that cross-checking. If the compromised CA and compromised server are giving those bad certs and bad SCTs to a large body of users, at least some of whom check STH inclusion proofs and gossip regularly with uncompromised CT log servers, auditors, or monitors, then they will likely be able to notice the discrepancy fairly quickly. However, if the evil twin CA+log is attacking only a few users in a much more targeted fashion, and is in sufficient control of the target users’ external connectivity to prevent them from gossiping with legitimate CT parties (or if the attacker simply happens to know that those users are running software that disable gossip for privacy reasons), then no one will ever have the opportunity to notice the discrepancy. I think this really needs to be made explicit. > An Auditor checking for log consistency might conclude that the compromised > log is acting maliciously, and is presenting a split view to its clients. How does this Auditor actually obtain both “views” of the compromised log? If the Auditor is obtaining log records directly from the compromised log server, then presumably the log server will send it only one of the two views. (Legitimate Auditors can be deceived through equivocation just as easily as clients!) This text needs to specify under what conditions the Auditor can notice the discrepancy: e.g., if it obtains one view from the log server and learns about a different view via gossip with other Auditors, Monitors, and/or relying parties that can and choose to gossip with it. > In this fashion the compromised log may be shunned and forced to shut down. > However, if an attacker targets a set of TLS clients that do not have access > to the legitimate log, they may not be able to detect this inconsistency. In > this case CT would need to rely on a distributed gossiping audit mechanism to > detect the compromise (see Section 5.6). > > In general, this sort of attack is analogous to a malicious CA creating a > bogus certificate and receiving an SCT (with no log entry) from a misbehaving > log (Section 4.2.1.2). The lack of a log entry prevents detection of the > bogus certificate by Monitors, and the presence of the SCT prevents rejection > by a CT-aware browser that accepts SCTs from the compromised log. Cheers Bryan > > _______________________________________________ > Trans mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/trans > <https://www.ietf.org/mailman/listinfo/trans>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
