You'll note that we have an open ticket on this (ticket #41: http://trac.tools.ietf.org/wg/trans/trac/ticket/41). I'd like to see this get some attention sooner rather than later (along with the precertificate discussion).
Melinda -------- Original Message -------- Subject: [Trans] Threat model outline, attack model Date: Thu, 11 Sep 2014 14:08:17 -0400 From: Stephen Kent <[email protected]> To: [email protected] <[email protected]> Since there was a suggestion that the current (-04) CT text contained an adequate threat model, and if a better one were needed, I should offer text, I have done so. Here is an initial cut at the sort of text I expect to see in an RFC dealing with security mechanisms. Steve -------- Threat Model Certificate Transparency (CT) is intended to detect and mitigate problems arising from mis-issuance of certificates, in the Web PKI context. The Web PKI context refers to the use of a set of Certification Authorities (CAs) that issue X.509 certificates to web servers to enable TLS-protected access by clients [cite WPKOPS?]. A certificate is characterized as mis-issued if the certificateis issued to an entity that is not authorized to represent the host (web server) named in the certificate Subject field or Subject Alternative Name extension. <do we want to focus exclusively on SAN vs. Subject?) <Discuss classes of adversaries, motivations, and capabilities> 1.Criminals 2.Hacktivists 3.Nation states (intelligence organizations) 4.Other? Attack Model and CT Mitigation Mechanisms Certificate mis-issuance may arise in one of several ways. The ways that CT helps detect and remedy mis-issuance depends on the context of the mis-issuance. 1.A non-malicious Web PKI CA may mis-issue a certificate as a result of an error or because it was the victim of a social engineering attack. In this case the CA has a record of the certificate and it is prepared to revoke the bogus certificate once it has been convinced of its error. If the CA is submitting the certificates it issues to one or more logs, there will be records of the bogus certificate. If one of Monitors to which the certificate was submitted is tracking the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, the only data needed to identify the bogus certificate is the Subject (SAN) and public key, both of which are available from the log. The presence of an embed SCT in the bogus certificate, or an SCT accompanying the bogus certificate does not appear to contribute to the mitigation. (See Note 1 below.) 2.A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar) which results in mis-issuance of one or more certificates. In this case the CA is not aware of the mis-issuance and may have no record of the certificate content. a.The bogus certificate(s) may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a standalone SCT. In either case, a Monitor to which the certificates had been submitted (and which is tracking the targeted Subject), would detect a bogus certificate and alert the targeted Subject. The Subject, in turn, would request the CA to revoke the bogus certificate. In this case, the CA will depend on the certificate serial number provided via the log entry, to effect revocation. (See Notes 1 + 2 below.) If TLS clients rejects a certificate when no SCT is present, this might motivate the attacker to log the bogus certificates, thus justifying such client behavior. (However, such client behavior needs to be defined in a way that is compatible with incremental deployment.) b.A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.) 3.A malicious Web PKI CA may mis-issue a certificate as a result of being bribed or compelled to do so. (A CA might be compelled to issue a bogus certificate my a government agency or a criminal organization.) This CA might be one or more tiers below a trust anchor (aka root CA). a.The bogus certificate(s) may have been submitted to one or more logs prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire a standalone SCT. In either case, a Monitor tracking the targeted Subject would detect a bogus certificate and alert the targeted subject. The Subject, in turn, would request the CA to revoke the bogus certificate. In this case, the CA may refuse, or substantially delay, to revoke the bogus certificate. (It could make excuses about inadequate proof that the certificate is bogus, or argue that it cannot quickly revoke the certificate because of local, legal concerns, etc.) In this case, the CT mechanisms have detected mis-issuance, but are not able to remedy the problem. (See Note 4 below.) b.A bogus certificate may not have been submitted to any logs. In this case, Monitors will not detect the bogus certificate. If clients reject a certificate that lacks (or is not accompanied by) an SCT, the attacker will be thwarted in this case. (See Note 3 below.) Notes: 1.If a CA submits the bogus certificate to logs, but these logs are not watched by a Monitor that is tracking the targeted Subject, CT will not mitigate a mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests its certificates be monitored. Absent such a guarantee, how do TLS clients and CAs know which set of Monitors will provide “sufficient” coverage. Unless these details are addressed, use of CT does not mitigation mis-issuance even when certificates are logged. 2.A CA being presented with evidence of a bogus certificate probably will require more than the serial number of the bogus certificate. It will want to verify the Issuer and Subject (SAN) to ensure that the certificate being revoked is not one that it has knowingly issued (which would fall under case #1). Other certificate fields and extensions may be of interest for forensic purposes, but are not required to effect revocation nor to verify that the certificate to be revoked is bogus. The SCT itself, because it contains a timestamp from a third party, is probably valuable for forensic purposes. 3.If a TLS client is to reject a certificate that lacks an embedded SCT, or is not accompanied by a post-issuance SCT, this behavior needs to be defined in a way that is compatible with incremental deployment. Issuing a warning to a (human) user is probably insufficient, based on experience with warnings displayed for expired certificates, lack of certificate revocation status information, and similar errors that violate RFC 5280 path validation rules. 4.The targeted Subject might request the parent or the offending CA to revoke the certificate of the non-cooperative CA. However, a request of this sort may be rejected, e.g., because of the potential for significant collateral damage. As the analysis above shows, logs play a critical role in enabling detection of certificate mis-issuance, although they do not, per se, perform such detection. Thus logs represent another target for adversaries who wish to effect certificate mis-issuance. If a log generates SCTs for an attacker, but does not provide the log entries for these SCTs to all, or some, Monitors, CT will not detect mis-issuance. Thus it is critical that Monitors be able to compare the results of log data acquisition to detect mis-behaving logs. Absent a protocol (a so-called “gossip” protocol) that enables Monitors to verify that data from logs are consistent, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. Even when a gossip protocol is deployed, it is necessary to describe how the CT system will deal with a mis-behaving or compromised log. For example, will there be a mechanism to alert all TLS clients to reject SCTs issued by such a log. Absent a description of a mitigation strategy to deal with mis-behaving or compromised logs, CT cannot ensure detection, much less remediation, of mis-issuance. Monitors also play a critical role in detecting certificate mis-issuance, for Subjects that have requested monitoring of their certificates. Thus Monitors represent another target for adversaries who wish to effect certificate mis-issuance. If a Monitor is compromised by, or is complicit with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting the Subject. This raises the question of whether a Subject needs to request certificate monitoring from multiple sources to guard against such failures.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
