On 11 September 2014 19:08, Stephen Kent <[email protected]> wrote: > 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.
Thanks! > > 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 certificate is 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?) This is not the only form of mis-issue - for example, the Baseline Requirements impose key size limits, lifetime limits, usage bits restrictions and so forth. EV adds even more stuff. > > > > > > <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. I think they are (or, at least, may be, depending on the nature of the bogosity), see above. > 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. The other recourse is to revoke directly in the browsers - either the whole CA or the offending certificate(s). This is what happened to DigiNotar, for example. > > > > > > 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. I do agree that we need to define the gossip protocol to complete the CT story. > 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
