based on comments from Ben, I made changes to the attack model text.
The diffs appear below.
Steve
------
*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.) _Since there is no requirement for a
TLS client to reject a certificate_If clients do not reject certificates
or otherwise notify usersIf clients do not reject certificates or
otherwise notify userswhen 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.
_Since TLS _Ifclients _are _donot _required to _reject _a certificate
that lacks (_certificates or _is not accompanied by) an SCT, or even
to_otherwisenotify _a user in such situations_users when no SCT is
provided, the preferred strategy for an attacker _will_is tonot _be
thwarted in this case_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. TLS clients will not reject a bogus certificate in this case,
because it is accompanied by an SCT.In this scenario, unless Monitors
“gossip” to detect conspiring logs, the bogus certificate will not be
detected. _Because_Untilthere _are no requirements_is a (mandatory to
implement) specificationfor _such _gossiping, an attack of this sort can
succeed_based on the current CT design_.__
__
*XX*.2.1
_Since there is no requirement that a _If TLS _client can be configured
to _clients do not reject _a certificate_certificatesthat _has_donot
appear to have been syntactically checkedby a log(as indicated by the
SCT), a malicious CA need not worry about failing a log-based check.
Similarly, __
_since_ifthere 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. _Since there is no requirement for a TLS client to _If
clients do not reject _a certificate that lacks (_certificates or _is
not accompanied by) an _otherwise notify users when no SCTis 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 clientsclient that relies on a syntactic checking
by a log will believe that the certificate has been syntactically
verifiedin this circumstance.
*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. _Since
there is no requirement for a TLS client to _If clients do not reject _a
certificate that lacks (_certificates or _is not accompanied by) an
_otherwise notify users when no SCT_, there is no motivation_is
provided, the preferred strategyfor an attacker _to submit the
certificate in this case_is to not log bogus certificates. (See Note 3.)
*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. 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 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. _Because_Untilthere is _no defined gossip
protocol_a (mandatory to implement) specification for gossiping, CT
_does not provide the necessary info_cannot be relied uponto detect this
form of mis-issuance. (See Note 5 below.)
Notes:
1.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. Moreover, if a certificate (or TLS handshake)
contains more than one SCT, unless the client verifies all of them if it
is to counter the threat posed by conspiring logs.
Absent a(mandatory to implement) “gossip” protocol that enables Monitors
to verify that data from logs are reported in a consistent fashion, CT
does notcannot 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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
