[Trans] Fwd: Threat model outline, attack model

[Melinda Shore <[e-mail]>]

You'll note that we have an open ticket on this (ticket
#41: http://trac.tools.ietf.org/wg/trans/trac/ticket/41).
I'd like to see this get some attention sooner rather than
later (along with the precertificate discussion).

Melinda


-------- Original Message --------
Subject: 	[Trans] Threat model outline, attack model
Date: 	Thu, 11 Sep 2014 14:08:17 -0400
From: 	Stephen Kent <[e-mail]>
To: 	[e-mail] <[e-mail]>



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.

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 certificateis 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?)





<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.
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.





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.



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.