Re: [Trans] Threat model outline, attack model

[Ben Laurie <[e-mail]>]

On 11 September 2014 19:08, Stephen Kent <[e-mail]> wrote:
> 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.

Thanks!

>
> 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 certificate is 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?)

This is not the only form of mis-issue - for example, the Baseline
Requirements impose key size limits, lifetime limits, usage bits
restrictions and so forth.

EV adds even more stuff.

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

I think they are (or, at least, may be, depending on the nature of the
bogosity), see above.

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

The other recourse is to revoke directly in the browsers - either the
whole CA or the offending certificate(s). This is what happened to
DigiNotar, for example.

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

I do agree that we need to define the gossip protocol to complete the CT story.

> 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.
>
>
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>