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
