[Trans] attack analysis, revised

[Stephen Kent <[e-mail]>]

The text below is my current take on an attack analysis for CT, revised to
reflect the goal of a broader, long-term scope, but emphasizing the current,
Web PKI-centric focus of the charter. It also has been changed based on 
several
comments from folks over the past week or so.  I think this analysis 
belongs in
6962-bis. It raises some questions that need to be answered as revisions 
proceed,
and suggests some topics that should be discussed in the security 
considerations section.

Comments (especially revised text) welcome,

Steve
-------

*XX*. Attack Model and Discussion of Detection and Mitigation Options

Certificate mis-issuance may arise in one of several ways. The ways that 
CT enables a Subject (or others) to detect and redress mis-issuance 
depends on the context and the entities involved in the mis-issuance. 
This attack model applies to the Web PKI context. If CT is applied to 
other contexts, each will require its own attack model, although most of 
the model described here is likely to be applicable.

Certificates are issued by CAs, so the top level differentiation is 
whether the CA that mis-issued a certificate did so maliciously or not. 
If not, then the next point of differentiation is whether the 
mis-issuance was the result of an accident or an attack. In the case of 
an attack, it is necessary to consider whether the certificate was 
logged, and if so, whether the log conspired with the attacker.

If the CA acted maliciously, it is necessary to ask whether it logged a 
mis-issued certificate. If so, then one must consider whether the CA 
conspired with one or more log operators, or conspired with one of more 
Monitors (for not self-monitoring Subjects).

The following sections examine each of these cases, for both syntactic 
and semantic mis-issuance. As noted above, the focus here is on the Web 
PKI context, although most of the analysis is applicable to other PKI 
contexts.

*XX*.1 A non-malicious Web PKI CA

If a certificate is submitted to a log, either prior to issuance (a 
pre-certificate), or post-issuance, syntactic mis-issuance can be 
detected, and noted. This will happen only if the log performs syntactic 
checks in general, and if the log is capable of performing the checks 
applicable to the submitted (pre-) certificate. A (pre-) certificate 
will be logged even if it fails syntactic validation, thus logging takes 
precedence over detection of syntactic mis-issuance. If syntactic 
validation fails, this will be noted in the SCT returned to the CA, and 
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 can be avoided by a CA if it makes use of 
logs that are capable of performing these checks for the types of 
certificates that are submitted, assuming that it acts on the feedback 
it receives. If a CA uses a log that does not perform such checks, or if 
the CA requests checking relative to criteria not supported by the log, 
then syntactic mis-issuance will not be detected.

*XX*.1.1 A CA may issue the certificate to an unauthorized party 
(semantic mis-issuance), as a result of an error or because it was the 
victim of a social engineering attack. We will refer to such a 
certificate as "bogus". In this case the CA has a record of the bogus 
certificate and it is prepared to revoke the bogus certificate once it 
has confirmed 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 is irrelevant 
to the mitigation procedure in this case. (See Note 1 below.) Because 
the mis-issuance was not malicious, there is no notion of a log operator 
or a Monitor conspiring with the CA.

*XX*.1.2 A non-malicious Web PKI CA may be the victim of an undetected 
attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance 
of a certificate. In this case the CA is not aware of the mis-issuance 
and may have no record of the certificate content.

*XX*.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 it. The Subject, in turn, will request the CA to 
revoke the bogus certificate. In this case, the CA will make use of the 
log entry (supplied by the Subject) to determine the serial number of 
the mis-issued certificate, and revoke it (after investigation). (See 
Notes 1 + 2.) If TLS clients reject a certificate when no SCT is 
provided, this might motivate the attacker to log the bogus 
certificates, which helps justify such client behavior. (See Note 3.)

*XX*.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 
TLS clients reject a certificate that lacks (or is not accompanied by) 
an SCT, the attacker will be thwarted in this case. (See Note 3.)

XX.1.2.3 The bogus certificate may have been submitted to logs that are 
conspiring with the attacker. In this case, Monitors will not detect the 
bogus certificate because the logs will suppress a bogus certificate log 
entry. TLS clients will not reject a bogus certificate in this case, 
because it is accompanied by an SCT. In this scenario, unless Monitors 
or Auditors "gossip" to detect conspiring logs, the bogus certificate 
will not be detected.

*XX*.2 A Malicious Web PKI CA

*XX*.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, 
syntactic mis-issuance can be detected, and noted. This will happen only 
if the log performs syntactic checks in general, and if the log is 
capable of performing the checks applicable to the submitted 
certificate. A (pre-) certificate will be logged even if it fails 
syntactic validation, thus logging takes precedence over detection of 
syntactic mis-issuance.

Because the CA is presumed to be malicious, the CA may cause the log to 
not perform checks, in one of two ways. The CA may assert that the 
certificate is being issued w/o regard to any guidelines (the "no 
guidelines" reserved CCID), or it may assert a CCID that has not been 
registered. In this fashion the CA can prevent the log from performing 
checks, and the SCT and log entry will not contain an indication of a 
failed check. Alternatively, the CA may submit a (pre-) certificate to a 
log that is known to not perform syntactic checks, and thus avoid 
syntactic checking.

If a client rejects a certificate that has not been syntactically 
checked (as indicated by the SCT), the first approach to subverting 
syntax checking will fail. If a client rejects a certificate that was 
logged by an operator that does not perform syntactic checks, the third 
approach noted above will fail. If a client is configured to know which 
versions of CABF guidelines exist, the second approach to avoiding 
syntactic checking also can be thwarted.

*XX*.2.2 Because the CA is presumed malicious, it may choose to not 
submit a 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. 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. (See Note 3.)

*XX*.2.3 A malicious CA may submit a certificate to one or more logs 
that collude with this CA to not perform syntactic checks, even though 
they claim to do so. In this case the syntactic mis-issuance will not be 
detected by logs. The log entry and the SCT for a syntactically invalid 
certificate will assert that the certificate syntax was verified. Unless 
Monitors also perform syntactic checks, this form of mis-issuance will 
not be thwarted in this case. TLS clients will believe that the 
certificate has been syntactically verified.

*XX*.2.4 A malicious CA may semantically mis-issue a certificate that is 
syntactically valid. Because it is syntactically valid, logs will not 
reject the bogus 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).

*XX*.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.)

*XX*.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.)

*XX*.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 trying 
to protect the targeted 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 consistency checking of logs and use of a "gossip" 
protocol. Until such checks are clearly defined and a gossip protocol is 
defined and deployed, CT does not provide the necessary info to detect 
this form of mis-issuance. When Auditors can detect a conspiring log, 
Monitors and clients can be alerted to it (how?). This would cause 
Monitors to avoid using such a log, and clients would reject SCTs 
generated by such a log. (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. If a Subject acts as 
its own Monitor, this problem is solved for that Subject. It is not 
clear how a Monitor becomes aware of all (relevant?) logs, including 
newly added logs. The means by which Monitors become aware of new logs 
MUST accommodate self-monitoring by a potentially very large number of 
web site operators.

2.A CA being presented with evidence of a bogus certificate, in the form 
of a log entry, will need to examine its records to determine if it has 
knowledge of the certificate in question. It also will likely require 
the targeted Subject to provide assurances that it is the authorized 
entity representing the Subject name (subjectAltname) in question. Thus 
a Subject should not expect immediate revocation of a contested 
certificate. 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 applicable criteria. The SCT and log 
entry, because each contains a timestamp from a third party, is probably 
valuable for forensic purposes (assuming a non-conspiring log operator).

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. Until a 
mechanism is defined that accommodates incremental deployment of this 
capability, attackers should not be expected to submit bogus 
certificates to (non-conspiring) logs.

4.A targeted Subject might request the parent of a malicious 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 a specific, bogus certificate identified by a Monitor, 
then the bogus certificate could be rejected in that fashion. This 
mitigation strategy calls for communication between Monitors and 
browsers, or between Monitors and browser vendors. Such communication 
has not been specified, i.e., there no standard ways to configure a 
browser to reject individual bogus certificates based on info provided 
by a Monitor. Moreover, the same or another malicious CA could 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 more 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 Monitors and 
clients reject certificates that contains SCTs from conspiring logs 
(based on info from Audotirs) will CT be able to deter use of such logs. 
Thus the means by which Auditors detect such logs, and inform TLS 
clients and Monitors must be specified. Moreover, if a certificate (or 
TLS handshake) contains more than one SCT, it appears that 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 a critical role in detecting semantic certificate 
mis-issuance, for Subjects that have requested monitoring of their 
certificates. A monitor (including a Subject performing self-monitoring) 
examines logs for certificates associated with one or more Subjects. It 
must obtain a list valid certificates for the Subject being monitored, 
in a secure manner.  A Monitor must not rely on a CA or RA database for 
this information or use certificate discovery protocols; this 
information must be acquired by the Monitor based on reference 
certificates it has obtained and installed. If a Monitor were to rely on 
a CA or RA database (for the CA that issued a targeted certificate), the 
Monitor would not detect mis-issuance due to malfeasance on the part of 
that CA or the RA, or due to compromise of the CA or the RA.  If a CA or 
RA database is used, it does detect mis-issuance by an unauthorized CA.  
A Monitor must not rely on certificate discovery mechanisms to build the 
list of valid certificates since such mechanisms might result in 
mis-issued certificates being added to the list.

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 too great for many web sites, and thus this 
mode of operation ought not be assumed to be universal when evaluating 
protection against Monitor compromise.

Now that certificate pinning has been approved as a standard, it is 
appropriate to factor in its use by TLS clients. It would appear that 
pinning will dramatically reduce the set of TLS clients that are 
vulnerable to mis-issuance; a client that pins a certificate for a web 
site would reject a bogus certificate even without use of any CT 
mechanisms. The security considerations section of 6962-bis needs to 
note this, as it suggests that deployment of pinning reduces the need 
for CT.