Steve, Thanks.
My primary concern with the analysis is that it does not discuss the practicality and resources and data required for the monitoring activity. It is quite possible that monitoring will not be done at all or will miss things or will be ineffective leaving the benefit of CT to largely as a deterrent as opposed to detection mechanism. Threat analysis may wish to point that out with significant emphasis since 6962 does not seem to emphasize this enough. I see CAs offering to perform monitoring service, which will not detect problems if the authorized CA or RA are compromised or have gone rogue. In summary, the last paragraph of the analysis may wish to point out the monitors may require subjects to use secure means to provide a list of valid certificates from time to time and for monitor to check the logs for mis-issuance against this list. 6962 does not address the critical aspect of monitoring from the perspective of checking that the certificates are legitimate. While just about everyone is against checking the certification path and certificate, but if the goal is to secure Web PKI, to improve user experience or at least protect less informed users from making bad choices when a browser barfs, I would think checking certificate, certification path, and even cipher suites including proper range for RSA public exponent are good things. On specifics of your analysis, on Note 2, I would think the CA may wish to get the whole certificate to verify that the certificate was issued by it by verifying the signature using its own public keys. From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Wednesday, October 01, 2014 1:51 PM To: [email protected] Subject: [Trans] updated definition and attack analysis text Ignoring (for the moment) the suggestion to not consider syntactic mis-issuance, and the topic of whether logs might perform syntax checks on certs submitted to them, I have revised the attack analysis text. It at least provides a sense of the style and structure one wants in such text, and which is missing from 6962-bis. I've expanded the definitions of mis-issuance based on the message exchanges Ben and I had, to more clearly describe the cases of syntactic and semantic mis-issuance that are outside of the scope for CT, or that may be detectable only if a Subject operates its own Monitor. I also added structure to group the attack cases, to make for easier reading. I' ve kept the "notes" style, but these could be folded into the attack case analysis if desired. (It would just introduce some redundancy.) Steve ------ 1. Goals and Definitions The goal of Certificate Transparency (CT) is to detect mis-issuance of certificates, in the Web PKI context. It is anticipated that CT will help deter mis-issuance, e.g., by providing information to an affected Subject to facilitate revocation of a mis-issued certificate. 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 does not conform to the requirements established by CA Browser Forum (CABF) documents for "domain validation" (DV) or "extended validation" (EV) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary forms syntactic mis-issuance and semantic mis-issuance. 1. A certificate may fail to meet the syntactic constraints imposed by the CABF guidelines. a. Most syntactic constraints from [CABF-Baseline] and [CABF-EV], can be checked via examination of a certificate chain, without reference to Subject-specific or CA-specific data. b. A few syntactic constraints require access to data specific to a CA or the Subject in question. 2. A certificate may fail to meet the semantic constraints imposed by the CABF guidelines. a. Most semantic constraints can be verified by comparing a certificate against one or more reference certificates for the Subject. b. Some semantic constraints cannot be verified by examining a certificate, even with reference certificate information. Most instances of the syntactic of mis-issuance can be detected by examining a certificate against a set of criteria extracted from the CABF guidelines. Based on whether a certificate purports to be a DV or an EV certificate, one can examine it against almost all of the syntactic constraints imposed by the guidelines. Appendix A, Section A.1 enumerates the syntactic criteria to be used in this case. These checks can be performed by a log before issuing an SCT, and if a (pre-) certificate fails these checks, it should not be issued. This behavior is RECOMMENDED to provide feedback to CAs, to detect potential syntactic mis-issuance before the certificate is issued. A few of the syntactic constraints cannot be verified in this fashion, e.g., because they require knowledge of the organizational relationships between "root" and subordinate CAs (see Section 9.3.3 of [CABF-Baseline].) Appendix A, Section A.2, notes these exception and notes that, in general, they cannot be checked by a Monitor or log, and thus there is no requirement to perform these checks. (A Monitor operated by a Subject on its own behalf has access to at least some of the data required to verify conformance to this latter set of syntactic constraints and thus SHOULD do so.) Detection of semantic mis-issuance as described in 2a above requires access to "reference" certificates associated with a specified Subject. (For purposes of this discussion, a reference certificate is a valid certificate issued to a specified Subject, consistent with the CABF guidelines.) The primary concern addressed by detection of semantic mis-issuance is that a certificate has been issued to an entity that is not authorized to represent the host (web server) named in the certificate Subject field (or subjectAltName extension). Other forms of semantic mis-issuance (2 b above) may arise due to procedural or operational violations of the CABF guidelines, but these may not be detectable by a third party, even with access to a reference certificate. For example, a Web PKI CA may fail to adhere to the audit procedures required in Section 15 of [CABF-Baseline]. CT elements (e.g., Monitors) are not able to detect these forms of mis-issuance because they are not externally visible. <Discuss classes of adversaries, motivations, and capabilities> 1. Criminals 2. Hacktivists 3. Nation states (intelligence organizations) 4. Other? 2. Attack Model and Mitigation Mechanisms Certificate mis-issuance may arise in one of several ways. The ways that CT enables a Subject (or others) to redress mis-issuance depends on the context of the mis-issuance, and thus it is appropriate to examine the context as part of an attack model 2.1 A non-malicious Web PKI CA If the certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. Because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again. Thus syntactic mis-issuance of this type will be thwarted. 2.1.1 A CA may issue the certificate to an unauthorized party (Section 1, 2.a), 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 (pre-) certificates for logging, there will be evidence of the mis-issuance in one or more logs. If a Monitor is "protecting" the targeted Subject, it will detect the mis-issuance, and will alert the Subject. Because the CA has a record of the mis-issuance, it should revoke the bogus certificate, after investigating, based on the information provided by the legitimate certificate Subject. The presence of an embedded SCT in the bogus certificate, or an SCT accompanying the bogus certificate does not contribute to the mitigation. (See Note 1 below.) 2.1.2 A non-malicious Web PKI CA may be the victim of an undetected attack (c.f., DigiNotar) which results in semantic 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. 2.1.2.1 The mis-issued certificate 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 that is protecting the targeted Subject will detect the bogus certificate and alert the targeted Subject. The Subject, in turn, will 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 reject a certificate when no SCT is present, this might motivate the attacker to log the bogus certificates, which helps justify such client behavior. 2.1.2.2 The 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.) 2.2 A Malicious Web PKI CA 2.2.1 If a certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. However, because the CA is presumed to be malicious, the certificate may be issued anyway. Thus checking for syntactic mis-issuance in this case does not, per se, prevent such mis-issuance. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case. 2.2.2 Because this CA is malicious, it may choose to not submit the certificate to a log. This avoids detection of syntactic mis-issuance by a log, but it also means there is no SCT for the certificate. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case. 2.2.3 The CA may submit the bogus certificate to one or more logs that collude with this CA, and thus do not perform syntactic checks. In this case the syntactic mis-issuance will not be detected by logs. Unless Monitors (or Auditors?) also perform syntactic checks, this form of mis-issuance will not be thwarted in this case. 2.2.4 The malicious CA may semantically mis-issue a certificate, that is syntactically valid. We will refer to such a certificate as "bogus". Because it is syntactically valid, logs will not reject the certificate. This situation might result because the CA was bribed or was compelled to issue the bogus certificate. (A CA might be compelled to issue a bogus certificate by a government agency or a criminal organization.) This CA might be one or more tiers below a trust anchor (aka root CA). 2.2.4.1 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.) 2.2.4.2 A bogus certificate 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 protecting the targeted Subject will detect a bogus certificate and alert the targeted subject. The Subject, in turn, will 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 the information logged by CT does not help remedy the problem. (See Note 4 below.) 2.2.5 A bogus certificate may have been submitted to one or more conspiring logs. These logs will issue SCTs, but will hide the log entries from some or all Monitors. Any Monitor from which the log is hiding data will not detect the bogus certificate, even if it is protecting the target Subject. If a client accepts an SCT from a conspiring log, then the client will not reject the bogus certificate on the basis of a missing SCT. In this case CT will not detect the semantically mis-issued certificate. Auditors are intended to detect logs that conspire to suppress log entries, based on XXX. [is the unspecified gossip protocol need here? If so, then until we have this protocol, CT does not provide the necessary info to detect this form of mis-issuance.] If Auditors detect conspiring logs, Monitors and clients can be alerted to conspiring logs. This would cause clients to not accept SCTs generated by these logs, in the future. (See Note 5 below.) Notes: 1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide "sufficient" coverage. Of course, if a Subject acts as its own Monitor, this problem is solved for that Subject. 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 (subjectAltname) to ensure that the certificate being revoked is not one that it has knowingly issued legitimately. Thus a Subject should not expect immediate revocation of a contested certificate in all cases. (The time frame in which a CA will respond to a revocation request usually is described in the CPS for the CA.) 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, based on [CABF-Baseline] criteria. 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 an SCT transported via the TLS handshake, 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. A 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. A browser might be configured to reject all certificates issued by the malicious CA, e.g., using a CA hot list distributed by a browser vendor. However, if the malicious CA has a sufficient number of legitimate clients, treating all of them as bogus still represents serious collateral damage. If one can configure a browser to reject the specific, bogus certificate identified by a Monitor, then the bogus certificate could be rejected in that fashion. Moreover, this calls for communication between Monitors and browsers, or between Monitors and browser vendors. Such communication is not specified. There are no standard ways to configure a browser to reject individual bogus certificates. Moreover, a malicious CA could easily issue new bogus certificates for the targeted Subject, which would have to be detected and rejected in this (as yet unspecified) fashion. Thus, for now, CT does not seem to provide a way to mitigate this form of attack, even though it provides a basis for detecting such attacks. 5. The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting s Subject does not see mis-issued certificates, it cannot alert the Subject. If one or mlore SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if clients reject certificates that contains SCTs from conspiring logs will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, the client MUST verify all of them if it is to counter the threat posed by conspiring logs. Absent a "gossip" protocol that enables Auditors to verify that data from logs are reported in a consistent fashion to many (all?) Monitors, CT does not provide protection against logs that may conspire with, or be victims of, attackers effecting certificate mis-issuance. When a gossip protocol is defined and deployed, it will be 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 of mis-issuance. Monitors play the critical role in detecting semantic 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 conspires with, an attacker, it will fail to alert a Subject to a mis-issued certificate targeting that Subject. This suggests that a Subject SHOULD request certificate monitoring from multiple sources to guard against such failures. Operation of a Monitor by a Subject, on its own behalf, avoids dependence on third party Monitors, but the burden of Monitor operation may be viewed as to great for many web sites, and thus this mode of operation ought not be assumed to be universal when evaluating protection against Monitor compromise.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
