Subject: [Trans] Threat model outline, attack model

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Sep 2014 14:08:17 -0400

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.

---

From: Katriel Cohn-Gordon <[email-masked]>
Date: Thu, 11 Sep 2014 20:43:34 +0100

I’ve also been thinking about a threat model, though your writing is much clearer than mine!

tl;dr: (a) There’s a lot of text about the details of revocation that I thought was out of scope for CT. (b) A client specification may answer many of the questions you raise about Monitors.

--
Katriel Cohn-Gordon
Student, Cyber Security
Merton College, Oxford

On Thursday, 11 September 2014 at 19:08, Stephen Kent wrote:  
> Certificate Transparency (CT) is intended to detect and mitigate...

Is it intended to mitigate problems? (-04) says so but immediately follows it with “the logs do not themselves prevent misissue, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance”

A fairer introduction might be “CT is intended to allow subjects to detect…"
> 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.

Or doesn’t follow certain regulations, or some other definition (e.g. comes from a root that the CA can but does not use to issue certificates). I think it should be up to individual Monitors to define what they consider to be mis-issued, though it makes sense to give a minimal criterion, and hence that the text should say something like “In the following, a certificate is characterised as mis-issued if… but any Monitor may choose to use an alternative definition, since CT is definition-agnostic."
>  
>  
> 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.

I think the key distinction to be made is between contexts that cause the certificate to be submitted to a non-malicious Log Server, and those that do not. As you say, in the former case a Monitor tracking the targeted Subject will detect the mis-issued certificate and set off the out-of-scope revocation process. In the latter, TLS clients which are not backwards compatible will refuse to accept the certificate, while TLS clients which do not yet enforce CT will act as they do today.

Once the certificate is detected, is the revocation process (e.g. what data the CA requires) in scope for this document?
>  
> 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.

I understood Monitors to be run by Subjects (or paid by Subjects to do their tracking for them), so I see no reason why they MUST offer to track anybody. It’s log servers for which you need sufficient coverage, though, not Monitors: one of the latter will suffice as long as it watches all the former. I don’t know what the current definition of “the set of all log servers” is (*); for the moment I assume it is defined by Google’s list for Chrome.

I agree it’s important to specify how Monitors can find out the set of log servers. (e.g. it’s Very Bad if I run my own monitor but don’t update its list, since then a mis-issued certificate submitted to a new log server will pass me by.)
>  
> 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.

What’s the precedent for defining incremental deployment in this type of document? I suppose the wording would be something like “TLS clients wishing to respect incremental deployment MAY choose to accept certificates without embedded SCTs, but…"
>  
> 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.

Again, is this in scope for CT? This issue exists in today’s infrastructure just as much (c.f. when people removed DigiNotar from trust lists).
>  
>  
>  
> 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.

I believe this is the same question as at (*): who controls the list of trusted logs? One assumes that anybody doing so (e.g. Chrome) would also run a Monitor, and thus detect misissuances and remove said logs from their list the same way they would have removed DigiNotar.

I think a section specifying the actions of TLS clients should answer a lot of these questions. Such a section would say in part that clients must keep lists of CAs and log servers, maintained either by themselves or by a trusted third party, and that the signatures on the cert and the SCT should be from entities in the respective lists. Whoever maintains the list undertakes to remove both bad CAs and bad log servers if they are detected.
>  
> 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.

Subjects must choose a trusted Monitor because the Monitor is by definition the thing that watches the logs; they can do this themselves or they can delegate to a third party, in which case they rely on that party not to be compromised. This doesn’t seem particular to CT: if I install a burglar alarm either I have to monitor it, or I have to pay someone else to monitor it and trust them to respond if it goes off, or I have to accept that the alarm might be ignored.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 11 Sep 2014 15:51:18 -0800

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 <[email-masked]>
To: 	[email-masked] <[email-masked]>

Steve
--------

Threat Model

1.Criminals

2.Hacktivists

4.Other?

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.

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

Notes:

which set of Monitors will provide “sufficient” coverage. Unless these

Absent a protocol (a so-called “gossip” protocol) that enables Monitors

---

From: Ben Laurie <[email-masked]>
Date: Fri, 12 Sep 2014 15:10:04 +0100

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

> 1. Criminals
> 2. Hacktivists
> 3. Nation states (intelligence organizations)
>
>
>
> 4. Other?
>
>
>
>
>
>
>
> 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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 15 Sep 2014 10:40:55 +0400

Stephen,

thank you for the formal description of treat model.

But I think that the Auditors should be mentioned in it too. If I am not
mistaken, they are designed to watch the certificates with suspicious
properties (CA permissions, etc.).

So the treats which are to be avoided using the Auditors seems to be
missing.

On Thu, Sep 11, 2014 at 10:08 PM, Stephen Kent <[email-masked]> wrote:

> A certificate is characterized as mis-issued if the certificate is issued
> 1. A non-malicious Web PKI CA may mis-issue a certificate as a result of
> 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
> 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
> certificates. In this case the CA is not aware of the mis-issuance and may
> have no record of the certificate content.
>
>
>
> 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
> 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.)
>
> 3. A malicious Web PKI CA may mis-issue a certificate as a result of
> 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).
>
> 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.)
>
> 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,
> 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.
>
>
>
> this sort may be rejected, e.g., because of the potential for significant
> collateral damage.
>
>
>
>
>
> 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.
>
>
>
> mitigation strategy to deal with mis-behaving or compromised logs, CT
> cannot ensure detection, much less remediation, of mis-issuance.
>
>
>

-- 
SY, Dmitry Belyavsky

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2014 14:52:52 -0400

Dimitry,

> But I think that the Auditors should be mentioned in it too. If I am 
> not mistaken, they are designed to watch the certificates with 
> suspicious properties (CA permissions, etc.).
>
> missing.is case, the CT mechanisms have detected mis-issuance, but are 
> not able to remedy the problem. (See Note 4 below.)

In 6962-bis (-04) the definition of the Auditor function is:

Auditors take partial information about a log as input and verify

that this information is consistent with other partial information

they have.

This is way too vague to be meaningful. So, I agree that an Auditor 
might be relevant
to the attack analysis, I didn't include it this time because there is 
not a sufficiently
detailed description of its functions. The examples of what an Auditor 
"can" do don't
mention checking cert content against a set of criteria. They focus on 
detecting log
inconsistencies. So, maybe Auditors should be mentioned in the 
discussion of detecting
log misbehavior.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2014 14:52:57 -0400

Ben,

Thanks for explaining what you and your co-authors have in mind when
you use the term mis-issuance. This is a very important first step toward
clarification for CT.
> restrictions and so forth.
So the scope of mis-issuance is much broader than what I had imagined.

I think we may need to add two things to 6269-bis:

     - normative references to CABF documents that are the basis for the 
broader
       set of cert issuance criteria that you note

     - maybe two appendices to enumerate the criteria. this will be 
critical if
       if the CABF docs contain other criteria that are outside the 
scope of CT,
       e.g., criteria that cannot be evaluated based on what is logged.

Do you agree?
>> ...
I agree that one might do that, but I am aware of no IETF standards for
doing so. My understanding is that DigiNotar, as a trust anchor, was
removed from the TA list. I am not aware (but then I am not a browser
vendor) of an equivalent mechanism for CAs below TAs. Also, the TA list
mechanism is not an IETF standard. We need to cite a spec, preferably
a standard, on how to deal with browser-based revocation. Is there an
appropriate CABF document that needs to become a normative reference?

> ...
I'm glad that we're in agreement here.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 15 Sep 2014 14:53:02 -0400

Katriel,
> I’ve also been thinking about a threat model, though your writing is much clearer than mine!
thanks.
> tl;dr: (a) There’s a lot of text about the details of revocation that I thought was out of scope for CT. (b) A client specification may answer many of the questions you raise about Monitors.
well, revocation, per se, may not be in scope for CT, but unless we can 
specify what actions
can/will be taken in response to the detection afforded by CT, this 
seems like a hard sell.
> Is it intended to mitigate problems? (-04) says so but immediately follows it with “the logs do not themselves prevent misissue, but they ensure that interested parties (particularly those named in…
fair point. I'll revise that text if there is general agreement to do so.
> A fairer introduction might be “CT is intended to allow subjects to detect…"
Well, it's not necessarily subjects, in the PKI sense. 6279-bis suggest 
that a Subject
can ask a Monitor to look for certs that have been issued without the 
authorization
of the Subject. Only if every Subject were to perform Monitoring for 
itself would your
text be accurate. Still, this will be easy to fix.
> Or doesn’t follow certain regulations, or some other definition (e.g. comes from a root that the CA can but does not use to issue certificates). I think it should be up to individual Monitors to de…
"regulations?" We need to be precise. Ben replied with a much more 
general characterization
of the term, which I believe is derived from CABF docs. I agree that we 
don't want each
Monitor to make up its own criteria; I don't agree that a "minimal" set 
of criteria is a
good idea. I would like to see uniformity in the criteria, based on 
published standards,
so that everyone knows what will be OK, and what is not OK.
> I think the key distinction to be made is between contexts that cause the certificate to be submitted to a non-malicious Log Server, and those that do not. As you say, in the former case a Monitor…
Submission to a log server, or lack thereof, is part of the analysis, as 
noted later. We may disagree
on what is the best way to structure the taxonomy.
> Once the certificate is detected, is the revocation process (e.g. what data the CA requires) in scope for this document?
I included the topic of what info is needed to help justify what is 
covered by an SCT. The
(initial) analysis I performed noted that the serial number is not 
required in all cases,
and it may not suffice in others (a malicious CA). So, to the extent 
that we are discussing
what data needs to be covered by an SCT, this part of the analysis is 
needed, and thus in scope.
> I understood Monitors to be run by Subjects (or paid by Subjects to do their tracking for them), so I see no reason why they MUST offer to track anybody. It’s log servers for which you need suffici…
I don't recall that the text made it clear who was running Monitors. if 
every Subject had to
run its own Monitor, it might be hard to argue that CT will provide very 
wide coverage in the
near term. Yet, near term, broad coverage is precisely the argument made 
to justify the need for
pre-certs. So, there is an important question here. I could easily 
envision Monitors that are
paid by Subjects to watch over certs. But, if that is part of the model, 
the doc needs to say
so. One Monitor, with a "pay for protection" business model probably 
would NOT suffice. Also,
relying on one company's list to define the set of log servers is not 
the sort approach we follow
in IETF standards, so ...

> What’s the precedent for defining incremental deployment in this type of document? I suppose the wording would be something like “TLS clients wishing to respect incremental deployment MAY choose to…
The IETF hates flag days; we almost never approve a protocol design that 
relies on all instances of
something to switch to a new something in unison. We're very big on 
backwards compatibility :-).
> Again, is this in scope for CT? This issue exists in today’s infrastructure just as much (c.f. when people removed DigiNotar from trust lists).
The analysis needs to address what happens in response to detection of 
mis-issuance, so that the
community can decide if the burden of deploying a big system of this 
sort is justified by the
benefits.
> I believe this is the same question as at (*): who controls the list of trusted logs? One assumes that anybody doing so (e.g. Chrome) would also run a Monitor, and thus detect misissuances and remo…
Chrome is a browser; Google is the vendor. If a vendor operates a 
Monitor, it can detect some
types of mis-issuance where knowledge of Subject cert info is not 
needed. For example, if
the cert issuance criteria require a minimum of 1024-bit RSA keys, any 
Monitor can detect a
cert with a 512-bit key, and flag it as "bad." But, if one is trying to 
detect that a cert
for foo.com was issued to the wrong entity, one needs to have 
authoritative info about the
real foo.com cert, or knowledge that foo.com has never requested a cert. 
A browser vendor
would have that info for itself, but not for web sites in general. So, I 
disagree with your
analysis that anyone who runs a log, such as a browser vendor, is in a 
position to detect
the form of mis-issuance that I had assumed was the primary motivation 
for CT. I agree that
any entity running a log could choose to run a Monitor, but by itself, 
one Monitor cannot
necessarily discover a misbehaving log.
> I think a section specifying the actions of TLS clients should answer a lot of these questions. Such a section would say in part that clients must keep lists of CAs and log servers, maintained eith…
Yes, these are topics that should be addressed in the description of TLS 
client behavior.
> Subjects must choose a trusted Monitor because the Monitor is by definition the thing that watches the logs; they can do this themselves or they can delegate to a third party, in which case they re…
Your analogy is reasonable. Nonetheless, the topic of trust in Monitors 
has a place in the
attack analysis.

Steve

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 16 Sep 2014 02:58:40 +0400

Hello Stephen,

On Mon, Sep 15, 2014 at 10:52 PM, Stephen Kent <[email-masked]> wrote:

> This is way too vague to be meaningful. So, I agree that an Auditor might
> be relevant
> to the attack analysis, I didn't include it this time because there is not
> a sufficiently
> inconsistencies. So, maybe Auditors should be mentioned in the discussion
> of detecting
> log misbehavior.
>
>
My fault. The certs with unnecessery permissions are a subject to be
Monitored, not Audited.

There is a high-level description of the Auditors here:
http://www.certificate-transparency.org/what-is-ct:
=====
Auditors are lightweight software components that typically perform two
functions. First, they can verify that logs are behaving correctly and are
cryptographically consistent. If a log is not behaving properly, then the
log will need to explain itself or risk being shut down. Second, they can
verify that a particular certificate appears in a log. This is a
particularly important auditing function because the Certificate
Transparency framework requires that all SSL certificates be registered in
a log. If a certificate has not been registered in a log, it’s a sign that
the certificate is suspect, and TLS clients may refuse to connect to sites
that have suspect certificates.
=====
It is not integrated as a part of neither RFC 6962 nor current draft, but
it provides a high-level explanation of the Auditors' role.

-- 
SY, Dmitry Belyavsky

---

From: Stephen Kent <[email-masked]>
Date: Tue, 16 Sep 2014 10:22:20 -0400

Dmitry,
> My fault. The certs with unnecessery permissions are a subject to be 
no problem.
> Auditors are lightweight software components that typically perform 
> two functions. First, they can verify that logs are behaving correctly 
> and are cryptographically consistent. If a log is not behaving 
> properly, then the log will need to explain itself or risk being shut 
> down. Second, they can verify that a particular certificate appears in 
> a log. This is a particularly important auditing function because the 
> Certificate Transparency framework requires that all SSL certificates 
> be registered in a log. If a certificate has not been registered in a 
> log, it's a sign that the certificate is suspect, and TLS clients may 
> refuse to connect to sites that have suspect certificates.
> =====
> It is not integrated as a part of neither RFC 6962 nor current draft, 
> but it provides a high-level explanation of the Auditors' role.
Until this text is part of an IETF document, it doesn't enter into our 
discussion :-).

Frankly it seems a bit counterproductive to have a separate site where 
info about CT is
being posted, while we try to discuss 69269-bis in this WG.

Steve

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 16 Sep 2014 20:12:25 +0400

Hello Stephen,

> being posted, while we try to discuss 69269-bis in this WG.

I think that the information I have quoted should either become the part of
the RFC or should be removed from the site. The RFC says too little about
the Auditors functions.

-- 
SY, Dmitry Belyavsky

---

From: Ben Laurie <[email-masked]>
Date: Thu, 25 Sep 2014 12:42:54 +0100

Apologies for delay.

On 15 September 2014 19:52, Stephen Kent <[email-masked]> wrote:
>>> to

This seems sensible. Note, though, that I would not want to constrain
mis-issue to be solely defined by CABF. Part of the point is that
anyone can monitor any aspect of issuance they want, and if they think
something is wrong, raise it to appropriate authorities...

>     - maybe two appendices to enumerate the criteria. this will be critical
> if
>       if the CABF docs contain other criteria that are outside the scope of
> CT,

It would certainly be interesting to know though I don't think it is
essential - an example of something CT cannot reveal is who generates
the key (obviously it is bad practice for CAs to do this for their
customers - I don't know if BRs or EV ban the practice though - in any
case, CT would not tell you who did it).

> appropriate CABF document that needs to become a normative reference?

As far as I know there are no standards in this area. Chrome contains
a blacklist of certificate hashes (from memory, its been a while since
I looked at this) - I don't know what other browsers do.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Sep 2014 11:06:50 -0400

Ben,

> something is wrong, raise it to appropriate authorities...
Mis-issuance is the primary (sole?) rationale for CT, so I am not 
comfortable
with the notion that mis-issuance is not well-defined.

> case, CT would not tell you who did it).
I'm puzzled; how would CT allow a Monitor to determine who generated the
key pair used in a cert that was logged? I don't understand your example 
here.
> I looked at this) - I don't know what other browsers do.
Well, if we can't say how this is done, preferably based on some standard,
then we can't make an argument that, after being being detected by CT, that
there is a fix. If so, then the security considerations section will have to
discuss this residual issue.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Sep 2014 15:28:35 +0100

> with the notion that mis-issuance is not well-defined.

Reality doesn't always make us comfortable :-)

We keep finding new ways for people to get certs wrong, and thus
creating new rules for them. Also, the exact rules are context
dependent, and may even depend on contracts and other things we can't
even see.

>>> critical

I said it wouldn't, so you are right to be puzzled.

> discuss this residual issue.

I think we have ample evidence that there are fixes to mis-issuance.
Some of them are based on standards, too (e.g. revoking in CRLs or via
OCSP).

---

From: Stephen Kent <[email-masked]>
Date: Fri, 26 Sep 2014 11:49:04 -0400

Ben,

> dependent, and may even depend on contracts and other things we can't
I don't accept that rationale as a basis for avoiding creating a definition
for mis-issuance.

The CABF Guidelines are revised over time. We can update the RFC to match.
We do that for other IETF Standards.

I don't understand the notion of context dependence for the definition
of mis-issuance. Can you provide some examples? Who decides what constitutes
a mi-issued cert inn what context?

I agree that a contracts between a CA and a Subject can include terms and
conditions that might cause aert to be "mis-issued" relative to those
Ts & Cs. But, I though CT was trying to enable Monitors to detect 
mis-issuance
on an Internet-wide scale. Violation of Ts & Cs is something that the
Subject and CA would be able to determine, but not others, in general.
At a minimum we need a set of universally-applicable issuance standards to
apply, based on two things:
- the syntax of the cert, which everyone can examine
- comparison of logged certs against reference certs, i.e., valid
certs already issued to (legitimate) Subjects. A Monitor can
perform this comparison if provided with a reference cert. if the
Monitor wants to perform additional checks, that may be fine

if we're going to create a standard that purports to detect mis-issuance,
but we can't define mis-issuance in a well-articulated, testable fashion, I
question the utility of this effort.
> I said it wouldn't, so you are right to be puzzled.
Then why cite this as as an example of mis-issuance, and yet claim that CT
is intended to detect mis-issuance? That's what I find puzzling.
> Some of them are based on standards, too (e.g. revoking in CRLs or via
I believe we have to be able to explain how mis-issuance (if it can be 
defined)
is detected by CT, and then how the detection provided by CT is used to 
address
the problem. That's why I believe we need an architecture and a 
threat/attack model, so
that there is a framework for explaining how CT fits into a solution to 
the problem.
When there are standards-bases ways to respond to mis-issuance detected 
by CT, then we
need to point to them. When there are not, we need to admit that and say 
that there
are residual problems, or that there are extant, but not standardized, 
mitigation
techniques.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 26 Sep 2014 17:00:49 +0100

On 26 September 2014 16:49, Stephen Kent <[email-masked]> wrote:
> Ts & Cs.

This is the kind of thing I meant.

> But, I though CT was trying to enable Monitors to detect
> mis-issuance

I want to enable as much to be detected as possible. Certainly if we
could only help in these narrow cases, that would be a cause for
concern - but my point is I don't think we can _fully_ nail down all
instances of mis-issuance.

> question the utility of this effort.

I didn't intend to suggest there was no point in defining mis-issuance
to the extent that its possible, just that I don't think its likely
we'll manage to completely define it, so we should not attempt to do
so. i.e. I would not like to see the RFC say "this is mis-issuance,
and nothing else is".

> is intended to detect mis-issuance? That's what I find puzzling.

I was supporting your claim that not all forms of mis-issuance are
detectable by simply looking at the certificate (though I guess almost
all are).

> that there is a framework for explaining how CT fits into a solution to the
> problem.
> When there are standards-bases ways to respond to mis-issuance detected by
> CT, then we

Sure thing.

---

From: Tao Effect <[email-masked]>
Date: Fri, 26 Sep 2014 18:25:56 -0700

Dear Stephen,

I've been reading through this thread with fascination. Thank you for bringing up the fact that CT needs to more clearly (and accurately) state what its threat model is, what sort of protections it does and does not provide to netizens, etc.

Had I found this thread earlier this week, I would have cited parts of it in a blog post I wrote on the same topic a few days ago [1].

I don't know whether you'll find that post useful or not, but for the sake of building a threat model, I think the visual diagrams there might help others more quickly grasp the sort of attack that CT should expect to face from certain actors. I know that I am primarily a visual thinker and learner, so for me visuals are essential to fully grasping complex systems.

The post does not discuss gossip because, to my understanding, the details of gossip have still not been fully agreed upon and specified in the RFC. Once they are, I will be very interested to re-evaluate what sort of impact might have.

Thanks again for raising this topic on the list.

Kind regards,
Greg Slepak

[1] http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 26 Sep 2014 22:38:49 -0400 (EDT)

On Fri, 26 Sep 2014, Tao Effect wrote:

> The post does not discuss gossip because, to my understanding, the details of gossip have
> still not been fully agreed upon and specified in the RFC. Once they are, I will be very
> interested to re-evaluate what sort of impact might have.

It would be even better it you would be part of the discussion here on
the trans working group to ensure the gossip protocol is implemented
in a way that is secure and useful to everyone, including yourself.

Paul

---

From: Tao Effect <[email-masked]>
Date: Fri, 26 Sep 2014 22:05:09 -0700

Dear Paul,

> in a way that is secure and useful to everyone, including yourself.

That's very kind of you to invite me to the discussion, so I spent some time just now thinking about how to do gossip right.

To start, I re-read the most recent document I have on gossip:

http://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf

Then something occurred to me: for some reason, perhaps because of how complicated the details of CT are, I hadn't realized that I was wrong about something, that now seems obvious. In my blog post, I'd written:

At its core, it introduces the concept of an append-only auditable log that is guaranteed to show the most recently issued SSL cert for any given domain (IF you’re able to ask it).

That is actually not true (for Auditors).

So then I re-read parts of Steve's original post in this thread that I had skipped. Indeed, there it was in his "Notes", the same thing I just now realized (he really did a fantastic job):

For Auditors, it doesn't mitigate mis-issuance even for *the same* log. I.e., a rouge CA/log combo (let's just call them "Clogs" :P) is free to step in, create a fraudulent certificate, use it for MITM, and then restore the original, undetected even by Auditors that successfully gossip STHs! For the same log!

The only ones who can stop this are Monitors, since they are able to request everything that's in the Clog and verify for themselves that there aren't any fraudulently issued certs.

And this, my friends, is Game Over.

I see no way that Monitors can save us here, even with successful gossip of STHs.

To save us, Monitors would need to monitor *all* logs for *all* domains and somehow successfully get this information to people who are being attacked with a fraudulent certificate.

Sorry, I tried, and in trying, I've realized that CT is more broken than I originally thought. I have no recommendations to give (except ones that you've heard already, and are likely "off topic" on this list).

:-\

Kind regards,
Greg Slepak

---

From: Ben Laurie <[email-masked]>
Date: Sat, 27 Sep 2014 12:53:31 +0100

On 27 September 2014 06:05, Tao Effect <[email-masked]> wrote:
> That's very kind of you to invite me to the discussion, so I spent some time
> just now thinking about how to do gossip right.
>
> Then something occurred to me: for some reason, perhaps because of how
> complicated the details of CT are, I hadn't realized that I was wrong about
> something, that now seems obvious. In my blog post, I'd written:
>
> At its core, it introduces the concept of an append-only auditable log that
> is guaranteed to show the most recently issued SSL cert for any given domain
> (IF you’re able to ask it).

This is not a guarantee CT aims to provide, nor, as you illustrate
below, is it a particularly useful guarantee.

> That is actually not true (for Auditors).

Quite.

> So then I re-read parts of Steve's original post in this thread that I had
> skipped. Indeed, there it was in his "Notes", the same thing I just now
> realized (he really did a fantastic job):
>

I agree that CT doesn't mitigate mis-issuance for subjects that do not
participate. On monitors and guarantees - anyone can run a monitor,
including, of course, the subjects themselves, so clearly there's no
barrier to participation for subjects who want to participate.

> For Auditors, it doesn't mitigate mis-issuance even for *the same* log.
> I.e., a rouge CA/log combo (let's just call them "Clogs" :P) is free to step
> in, create a fraudulent certificate, use it for MITM, and then restore the
> original, undetected even by Auditors that successfully gossip STHs! For the
> same log!
>
> The only ones who can stop this are Monitors, since they are able to request
> everything that's in the Clog and verify for themselves that there aren't
> any fraudulently issued certs.
>
> To save us, Monitors would need to monitor *all* logs for *all* domains and
> somehow successfully get this information to people who are being attacked
> with a fraudulent certificate.
>
> Sorry, I tried, and in trying, I've realized that CT is more broken than I
> originally thought. I have no recommendations to give (except ones that
> you've heard already, and are likely "off topic" on this list).
>
> :-\
>
> Kind regards,
> Greg Slepak
>
> --

---

From: Tao Effect <[email-masked]>
Date: Sat, 27 Sep 2014 09:58:56 -0700

Dear Ben,

On Sep 27, 2014, at 4:53 AM, Ben Laurie <[email-masked]> wrote:

> I agree that CT doesn't mitigate mis-issuance for subjects that do not participate.

If by "participate" you mean owners who submit their certs to logs, CT doesn't detect mis-issuance even for those who do, as that email explained.

> On monitors and guarantees - anyone can run a monitor,

"No barrier"? Subjects (domain owners) would need to monitor *all* the logs out there.

There will be like 1000+ logs out there.

Each log will be how large (gigabytes?), and CT is not P2P, so Monitors must *poll* 1000+ logs constantly for updates, just for the purpose of detecting mis-issuance.

On top of this, Section 4.6 of your RFC (bis-04) states that logs are not required to send monitors everything they ask for, making it unclear whether a log is misbehaving or not.

This is not practical.

###

But that is all besides the point.

The point is that gossip doesn't detect mis-issuance, whether or not "subjects participate" in CT or not.

Kind regards,
Greg Slepak

---

From: Matt Palmer <[email-masked]>
Date: Sun, 28 Sep 2014 07:19:40 +1000

> There will be like 1000+ logs out there.

"Citation needed", as the Wikipedeans say.  I'm not sure how you could
possibly come to that conclusion.

Even if there were that many logs in existence, the number of logs that a
subject would have to monitor would be limited to the set of logs that are
trusted by browsers and other SSL-using clients who implement CT (because
one or more of those logs are going to *have* to receive the certificate in
order for the log entry to be of any use).

While the requirements for running a log that is eligible for inclusion in
Chromium aren't *hugely* arduous, they're still not so trivial that every
man and his dog is going to be doing it.  In fact, given that there's no way
to monetize running a log, there are strong *dis*incentives to doing so
"just for the hell of it".

- Matt

---

From: Tao Effect <[email-masked]>
Date: Sat, 27 Sep 2014 14:41:37 -0700

> possibly come to that conclusion.

I am citing your own documentation:

"we think “every major CA” is within limits of feasibility"

http://www.certificate-transparency.org/faq

And using Jacob's numbers from here:

http://www.ietf.org/mail-archive/web/therightkey/current/msg00745.html

> Please also see these estimates which are even higher:
> 
> https://zakird.com/slides/durumeric-https-imc13.pdf
> 
> "Identified 1,832 CA certificates  belonging to 683 organizations"
> "311 (45%) of the organizations were provided certificates by
> German National Research and Education Network (DFN) "
> 
> http://link.springer.com/chapter/10.1007%2F978-3-642-39884-1_28
> 
> "More than 1200 root and intermediate CAs can currently sign
> certificates for any domain and be trusted by popular browsers."
Now, should the number be less than 1000, it will still be in the hundreds, and that is still impractical for Monitors to provide any sort of a useful service to most website owners.

Not to mention that it does nothing to help with gossiping clients, they will still be MITM attacked, and they will likely not notice it for the aforementioned reasons.

Kind regards,
Greg Slepak

---

From: Ralph Holz <[email-masked]>
Date: Sun, 28 Sep 2014 14:17:38 +0200

Hi,

> http://www.ietf.org/mail-archive/web/therightkey/current/msg00745.html

It is interesting that this rumour, which was started with the EFF's
talk at DEFCON years ago, is still perpetuated. It has been disputed
numerous times and is most likely inflated by at least a factor of 2.

* DFN is not a collection of many CAs, but of one CA whose RAs are
identified in intermediate certificates - they do not hold the private
keys corresponding to the latter, however. They even document this fact
publicly.

* The number of organisations in the Mozilla root store holding CA
certificates is below 100, although about 60 are waiting for inclusion.
The number of root certificates is higher, but that is because many
organisations operate under several brand names and use different root
certs for different purposes (most notably EV).

* That leaves us with an undisclosed number of intermediate certificates
issued by CAs. Some of these may indicate subordinate CAs. This is a
problem as browsers often cache such certs for later use (once trusted,
always trusted). Mozilla has thus made it an obligation for CAs to
disclose their subordinate CAs if they are not identical to the "mother
organisation".

The latter factor gives huge leeway in the number of certs accepted by
browsers as root certs. But however you look at it, the number of such
certs will be comfortably below 1000 - anything from the 150+ root certs
in the Mozilla store up to a few hundred.

Applied to CT, these numbers matter even less if gossiping, monitoring
and auditing can be used. First, logs only accept a limited number of
CAs, as a anti-flooding protection. I'd love to hear what CAs plan here
- if their subordinates are eligible for acceptance by a log or not. And
second, the gossiping between logs and between clients has an important
effect: an attacker would have to compromise quite a few logs to make
sure his MITM is effective. Just requiring, say, 3 SCTs in a handshake
would already result in considerable work for the attacker (I know the
current number is 2, though). There is no need for clients to cooperate
with 1000 logs.

That's my understanding at least - happy to hear comments.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18010
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Ben Laurie <[email-masked]>
Date: Sun, 28 Sep 2014 15:30:17 +0100

On 27 September 2014 17:58, Tao Effect <[email-masked]> wrote:
> participate.
> If by "participate" you mean owners who submit their certs to logs, CT
> doesn't detect mis-issuance even for those who do, as that email explained.

By "participate" I mean monitor (or cause to be monitored) the logs.

> Each log will be how large (gigabytes?), and CT is not P2P, so Monitors must
> *poll* 1000+ logs constantly for updates, just for the purpose of detecting
> mis-issuance.

The total size is presumably some smallish multiplier of the total
number of valid certs, so certainly not terabytes as you imply. I
don't believe there will be as many as 1,000 logs, though I do believe
CT would still work if there were.

> On top of this, Section 4.6 of your RFC (bis-04) states that logs are not
> required to send monitors everything they ask for, making it unclear whether
> a log is misbehaving or not.

You really are clutching at straws. Yes, perhaps 4.6 should say that
at least one entry must be returned.

> "subjects participate" in CT or not.

Gossip detects misbehaviour on the part of logs (in particular,
advertising different logs to different people).

---

From: Tao Effect <[email-masked]>
Date: Sun, 28 Sep 2014 10:01:08 -0700

Dear Ralph,

> in the Mozilla store up to a few hundred.

Thanks for clarifying some of this!

This is just Mozilla, however. Even if we go by your numbers, we still need to do a union on the certs accepted by other browsers, and other operating systems.

Do you happen to have numbers for that too?

> Just requiring, say, 3 SCTs in a handshake
> would already result in considerable work for the attacker

Yes, I think that would improve things.

> (I know the current number is 2, though).

The current number is 1 according to the most recent version of the RFC I could find (bis-04):

https://raw.githubusercontent.com/google/certificate-transparency-rfcs/master/draft-ietf-trans-rfc6962-bis-04.txt

> There is no need for clients to cooperate with 1000 logs.

Well, if they want to know for certain that they weren't MITM'd, they're going to have to search up to a 1000 logs (or several hundred, whatever the number happens to be).

Kind regards,
Greg Slepak

---

From: Tao Effect <[email-masked]>
Date: Sun, 28 Sep 2014 10:04:42 -0700

> Well, if they want to know for certain that they weren't MITM'd, they're going to have to search up to a 1000 logs (or several hundred, whatever the number happens to be).

Erm, sorry, not "for certain", because even if they did scan those logs for inappropriate certs, that still won't tell them whether or not the certificate is fraudulent for two reasons:

1. Only the website owner determines whether the certificate is actually fraudulent. Clients cannot determine this with CT, no matter how much gossip they do, nor how many logs they query.

2. Similar to #1 but not identical is the possibility that a revoked certificate was used to MITM.

Kind regards,
Greg Slepak

---

From: Matt Palmer <[email-masked]>
Date: Mon, 29 Sep 2014 08:35:29 +1000

> I am citing your own documentation:

I had nothing to do with the content on that webpage.  Not everyone
interested in CT works for Google, y'know.

> http://www.ietf.org/mail-archive/web/therightkey/current/msg00745.html

The word "major" does not appear anywhere in the content of that resource. 
Thus, you're comparing apples with oranges -- the Google CT FAQ suggests
that "every major CA" may run a log, while your resource says there may be
between "more than 1200" and 1832 CA certificates (total, comprising both
roots and intermediates) in active existence, but with no indication of how
many of those may be considered "major".

- Matt

-- 
The New York Times: the paper that asks for more verification from its
readers than its writers.

---

From: Greg <[email-masked]>
Date: Sun, 28 Sep 2014 20:41:44 -0700

Dear Matt,

> interested in CT works for Google, y'know.

Right you are, my apologies, I should have said "Google's documentation".

> many of those may be considered "major".

Thank you (and Ralph) for bringing this up!

I've updated the blog post to add this sentence in bold underneath the attack picture (at the end of claim #1):

Edit September 28, 2014: The number of CAs out there is disputed [1], and not all CAs will necessarily [2] have their own log.

[1] http://www.ietf.org/mail-archive/web/trans/current/msg00604.html
[2] http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/www.ietf.org/mail-archive/web/trans/current/msg00606.html

Kind regards,
Greg Slepak

---

From: Gervase Markham <[email-masked]>
Date: Mon, 29 Sep 2014 14:23:30 +0100

On 28/09/14 13:17, Ralph Holz wrote:
> issued by CAs.

And why would any of those want to run a log anyway, more than a random
person? I'd expect them in most cases to submit their certs to the log
run by the parent CA.

I wonder also if small CAs would pool resources to run a log. After all,
it's not a customer-facing function.

So I'd be surprised if we see 60 logs.

Gerv

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Sep 2014 10:52:57 -0400

Ben,

> On 26 September 2014 16:49, Stephen Kent<[email-masked]>  wrote:
>> Ben,
>>
>>> ...
I didn't see replies to my other comments above.

As for the contract example, I think this is out of scope for anything we
are trying to do. If we say that CT enables detection of mis-issuance based
on the model I described in my proposed Appendix, we cover a lot of cases
that are defined objectively, are universal, and have a basis in the 
Guidelines
to which you alluded when you mentioned EV certs. We can say that 
examination of
logs MAY be enable detect ingother forms of mis-issuance, but that 
because we
have no definition of what that might be, it's out of scope for this doc.
> instances of mis-issuance.
And I don't think we cannot discuss, not make design decisions, based on
types of mis-issuance we can't define.
> so. i.e. I would not like to see the RFC say "this is mis-issuance,
Again, I disagree. We should define what we can and make design decisions
based on that definition. Anything else that might be considered 
mis-issuanve,
is out of scope for purposes of this work. This is the sort of 
delineation that
we often impose on RFCs; we define a scope for a standard and declare 
that other
stuff is out of scope, relative to the standard.
> detectable by simply looking at the certificate (though I guess almost
Well, there are a lot of examples that I think most folks will agree are 
mis-issuance,
and which are syntactic. The original case I envisioned, issuing a cert 
to the wrong
entity, is addressed by having a reference to the "right" cert or to 
equivalent data. There
is also the interesting case of non-existence of issuance, as asserted 
by the entity
that controls the Subject name. I didn't address that, but one could 
imagine doing so.
>> are residual problems, or that there are extant, but not standardized,
OK. I think we may be converging on some aspects of this issue.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Sep 2014 15:16:15 -0400

Greg,

I'm impressed by your web site graphics.

Unfortunately, for RFCs, we have to stick with ASCII art, which is 
painful and
only black and white.  So, although I agree that diagrams are very helpful
when trying to understand the CT context, I won't be able to incorporate 
them
into my text.

I have not visited the Google CT web site because I focus on what we do 
in IETF
WGs, and for that only material published in that context counts. In 
fact, I have
complained about referring to the CT web site to gain a better understanding
of what 6962-bis is supposed to mean; discussion and explanations of CT 
need to
be part of the IETF archival data, not on an independent web site. But, 
that's another
issue.

I'm continuing to revise the attack analysis, based on my analysis of the
CABF guidelines, more thought, and helpful feedback from folks like Rick 
and Santosh.
I'll post an updated version of the attack analysis later this week,

Steve

---

From: Ralph Holz <[email-masked]>
Date: Mon, 29 Sep 2014 23:01:51 +0200

Hi Gervase,

I agree; I was trying to give an upper bound.

I think the original CT design documents spoke about "maybe 30 logs, but
certainly a lot less than 1000" or so.

Ralph

On 09/29/2014 03:23 PM, Gervase Markham wrote:
>> * That leaves us with an undisclosed number of intermediate
>> certificates issued by CAs.
> 
> And why would any of those want to run a log anyway, more than a
> random person? I'd expect them in most cases to submit their certs to
> the log run by the parent CA.
> 
> I wonder also if small CAs would pool resources to run a log. After
> all, it's not a customer-facing function.
> 
> _______________________________________________ Trans mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/trans
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 30 Sep 2014 13:18:41 +0100

On 29 September 2014 15:52, Stephen Kent <[email-masked]> wrote:
> is out of scope for purposes of this work. This is the sort of delineation
> that
> we often impose on RFCs; we define a scope for a standard and declare that
> other

Then perhaps we should have a broader scope. Focusing on mis-issuance
seems to lead to all sorts of, IMO, unnecessary complications.

It might be simpler to define CT as a mechanism for allowing the
public examination of the contents of all issued certificates, without
getting into exactly what might be done as a result of that
examination. Detecting mis-issuance is, of course, an obvious example.