Ben,
Happy to oblige. The revised text is attached.
As for your comments:
I still don't really understand this point: the log has no power to
check syntax that is not also available to a client,
In principle that's true, but in practice we have seen many instances
where client software
fails to perform checks established by standards. Thus logs represent an
opportunity to
do a better job (since they are new code) and perhaps help save clients
from bad code.
so I don't see how the log checking/not checking syntax is
interesting - a malicious CA presumably cannot know what all clients
will do? Because of this, I also still do not see the real value of
logs checking syntax - I am not fundamentally against it, but it
doesn't seem to me to add much.
A malicious CA can determine (via testing) which clients, by browser
type and version,
fail to perform certain syntactic checks. If the CA is creating a bogus
cert with a
particular set of clients in mind, this may suffice.
It is not clear to me that gossip has to be mandatory. So long as
some fraction of participants gossip, then clients are protected
from non-targeted attacks. Obviously this does not remove the need
to specify gossip, which is clearly required for CT to fully realise
its potential.
Remember that IETF standards almost always specify mandatory to
implement (MTI) features, not
mandatory to use (MTU) features. I believe your comment above supports
my argument that gossip needs
to be MTI, but not MTU.
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
error, an attack, or malicious behavior by a CA. In the case of an attack or
malicious behavior by a CA, it is necessary to consider whether the certificate
was logged. If the certificate was logged, it is necessary to consider whether
the log(s) may have conspired with the attacker. Finally, one must consider the
possibility that a third party Monitor might collude with an attacker (or a
malicious CA). Here�s an taxonomy of attacks and assumptions about the attack
environment:
1. CA
1.1. Non-malicious CA
1.1.1. Error
1.1.2. Attack victim
1.1.2.1. Certificate logged
1.1.2.1.1. Benign log
1.1.2.1.1.1. Self-monitor
1.1.2.1.1.2. Benign 3rd party Monitor
1.1.2.1.1.3. Conspiring 3rd party Monitor
1.1.2.1.2. Conspiring log
1.1.2.2. Certificate not logged
1.2. Malicious CA
1.2.1. Certificate logged
1.2.1.1. Benign log
1.2.1.1.1. Self-monitor
1.2.1.1.2. Benign 3rd party Monitor
1.2.1.1.3. Conspiring 3rd party Monitor
1.2.1.2. Conspiring log
1.2.2. Certificate not logged
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 Non-malicious Web PKI CA context
If a pre-certificate is submitted to a log, prior to issuance of a certificate,
syntactic mis-issuance can (optionally) 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. Because this case assumes a non-malicious CA, the CA will
remedy the syntactic problem and re-submit the pre-certificate to a log. In
this case syntactic checking by a log helps avoid issuance of a malformed
certificate.
If a certificate is submitted by its Subject, we assume that the Subject will
contact the issuer and request a new certificate if a log indicates that the
certificate failed the applicable syntactic check. Here too syntactic checking
by a log enables a Subject to be informed that its certificate is malformed and
thus may hasten issuance of a replacement certificate.
If the certificate was submitted by a third party, that party might contact the
Subject or the issuer, but because the party is not the Subject of the
certificate it is not clear how the issuer will respond.
Bottom line: Syntactic mis-issuance of a certificate 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, and if the CA 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 or avoided by this mechanism. Syntactic
mis-issuance can be remedied if a Subject submits a certificate to a log that
performs syntactic checks, and if the Subject requests the issuer to fix
problems detected by the log. (The issuer is presumed to be willing to re-issue
the certificate, correcting any problems, because the CA is not malicious.)
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 affected Subject, it will
detect the mis-issuance, and will alert the Subject. Because the CA has a
record of the mis-issuance, it should be able to 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 can alert the Subject. 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 clients do not reject certificates or
otherwise notify users when no SCT is provided, the preferred strategy for an
attacker is to not log bogus certificates. (See XX.1.2.2 and 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 clients do not reject
certificates or otherwise notify users when no SCT is provided, the preferred
strategy for an attacker is to not log bogus certificates. (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. In
this scenario, unless Monitors �gossip� to detect conspiring logs, the bogus
certificate will not be detected. Until there is a (mandatory to implement)
specification for gossiping, an attack of this sort can succeed.
XX.1.2.4 If a semantically bogus certificate is submitted to non-conspiring
logs, a Subject performing self-monitoring will be able to detect the bogus
certificate and request revocation. If a Subject relies on a third-party
Monitor, and that Monitor conspires with the attacker, the Subject will not be
alerted and thus will not request revocation.
XX.2 Malicious Web PKI CA context
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 several ways.
1. The CA may assert that the certificate is being issued w/o regard to any
guidelines (the �no guidelines� reserved CCID).
2. The CA may assert a CCID that has not been registered, and thus no log will
be able to perform a check.
3. the CA may check to see which CCIDs a log declares it can check, and chose a
registered CCID that is not checked by the log in question. 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.
4. The CA may submit a (pre-) certificate to a log that is known to not perform
any syntactic checks, and thus avoid syntactic checking.
If TLS clients do not reject certificates that do not appear to have been
syntactically checked by a log (as indicated by the SCT), a malicious CA need
not worry about failing a log-based check. Similarly, if there is no
requirement for a TLS client to reject a certificate that was logged by an
operator that does not perform syntactic checks, the fourth approach noted
above will succeed as well. If a client were configured to know which versions
of certificate types are applicable to its use of a certificate, the second and
third strategies noted above could 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 do not reject
certificates or otherwise notify users when no SCT is provided, this form of
mis-issuance will succeed. (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 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. A TLS client that relies on a
syntactic checking by a log will believe that the certificate has been
syntactically verified in this circumstance.
XX.2.4 A malicious CA may semantically mis-issue a certificate that is
syntactically valid. Because it is syntactically valid, logs will not mark the
bogus certificate as failing a syntax check. The semantically bogus certificate
may have been issued because the CA was bribed or was compelled to issue the
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 do not reject
certificates or otherwise notify users when no SCT is provided, the preferred
strategy for an attacker is to not log bogus certificates. (See Note 3.)
XX.2.4.2 A bogus pre-certificate may have been submitted to one or more logs,
to acquire an embedded SCT, a certificate may have been submitted post-issuance
(to acquire a standalone SCT). In either case, a (non-conspiring) Monitor
protecting the targeted Subject will detect a bogus certificate and alert that
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.4.3 If a third-party Monitor conspires with the malicious CA, then it will
not notify the targeted Subject when a bogus certificate is logged. If a
Subject performs self-monitoring this sort of attack will be avoided.
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 (even a self-Monitor) from which the log is hiding
data will not detect the bogus certificate, even if it is trying to protect the
targeted Subject. In this case CT will not detect the bogus certificate.
The audit function is intended to detect logs that conspire to suppress log
entries, based on consistency checking of logs and use of a �gossip� protocol.
It is assumed that Monitors will perform the audit functions described in
Section <insert #>.
A Monitor performing an audit function could alert its clients if the Monitor
detects evidence of malfeasant log operation. This would cause Monitors to
avoid using such a log, and clients would reject SCTs generated by such a log.
Until there is a (mandatory to implement) specification for gossiping, CT
cannot be relied upon to detect this form of mis-issuance. (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 also is not clear how a Monitor becomes aware of
all (relevant?) logs, including newly created 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 were 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 probably will avoid
submitting bogus certificates to (non-conspiring) logs as a means of evading
detection.
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 this specification
were to require that a browser can be configured 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 are no standard ways to
configure a browser to reject individual bogus certificates based on info
provided by an external entity such as 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 definition of an audit function, 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 an audit) will CT be
able to deter use of such logs. Thus the means by which a Monitor performing an
audit function detect such logs, and inform TLS clients must be specified for
this to be effective.
Absent a (mandatory to implement) �gossip� protocol that enables Monitors to
verify that data from logs are reported in a consistent fashion, CT cannot
claim to provide protection against logs that may conspire with, or are 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.�
Note: 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 provided by a Subject.�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.
As noted above, 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, as noted above. It is RECOMMENDED that a Subject
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. However, 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.
A final note: Now that certificate pinning has been approved as a standard
(currently in the RFC Editor�s queue), 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 without use of any
CT mechanisms. The security considerations section of 6962-bis needs to note
this, since deployment of pinning appears to reduces the need for CT in the Web
PKI context.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
