Subject: Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

From: Bryan Ford <[email-masked]>
Date: Fri, 24 Jul 2015 00:27:37 +0200

> From: Melinda Shore <[email-masked]>
> Subject: [Trans] Call for adoption, draft-linus-trans-gossip-ct
> Date: July 23, 2015 at 2:03:24 PM GMT+2
> To: "[email-masked]" <[email-masked]>
> 
> Hi, all:
> 
> This is a call for adoption of
> http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/
> as a working group deliverable.  The call closes on August 6.

While the draft represents a fine start at defining a gossip mechanism, I would like to express serious reservations about the draft’s basic premise that a gossip mechanism is the best approach - or even an adequate approach - “to detect misbehavior by CT logs”, to quote the draft’s self-stated purpose.  As such, I have serious reservations about the WG adopting the draft, not because there’s anything wrong with the content of the draft per se but because gossip is simply not the right approach.

First, the gossip approach creates severe privacy problems, which are already well-discussed so I won’t reiterate them.

Second, the gossip approach can’t ensure that privacy-sensitive Web clients (who can’t or don’t want to reveal their whole browsing history to a Trusted Auditor) will ever actually be able “to detect misbehavior by CT logs”, if for example the misbehaving log’s private key is controlled by a MITM attacker between the Web client and the website the client thinks he is visiting.

Suppose, for example, it ever so happens that a single company ends up running both a log server and a [sub-]CA, and keeps both in the same poorly-protected safe.  If an attacker can steal those two private keys, then the attacker can silently MITM any CT-aware client all it wants, by producing all the [non-EV] certificates it needs with a valid SCT, valid STH inclusion proofs in a fake log, etc.  The web client isn’t going to learn about the problem via gossip with the website because that’s the MITM attacker, and the client can’t gossip with anyone else without the serious privacy risk of trusting a single audit server with his entire browsing history.  If the “trusted audit server” is actually co-located with the client, then the audit server in turn can’t gossip with the rest of the world without creating the same privacy risk.  Even if the client does voluntarily gossip with a remote trusted audit server, the MITM attacker - e.g., an ISP-level or state-level attacker - might simply block connections to all well-known audit servers.

Is it “too unlikely” that an attacker can compromise both a log server key and a CA key?  Even if some CT policy is established that a single company is never allowed to run both a log server and hold a [sub-]CA key, which might not be a bad idea, it doesn’t seem beyond reason that some state-level attackers are incapable of quietly exfiltrating (or just quietly subpoenaing) both a log server key and a CA key, and then they get the same, silent MITM power as they can get now.

Thus, while CT does potentially “raise the bar” a bit by requiring a MITM attacker to steal both [any one] CA key and [any one] log server key, the set of all well-known log servers still just forms another new weakest-link security chain, just like the set of all CAs and sub-CAs form an old weakest-link security chain.  While “best of two weakest-link chains” is admittedly better than one weakest-link chain, it does not seem like the best we can do or the target we should be aiming for.

I posted an E-mail last week suggesting an alternative approach, in which log servers would not individually sign their STHs but instead collectively sign them with the active participation of (a suitable quorum of) the auditors and/or monitors watching their logs.  But I got no response to that, so I’d like to try again.

In short: the log server would propose log entries, but the auditors and/or monitors contribute to the STH signature, only after performing at least the “auditing” function of verifying that the log server is behaving like a correct log server.  In particular, all participants could proactively verify that the log server never forks or reverts the log, never signs something syntactically invalid or with a wildly-incorrect timestamp (say +/- 24 hours), etc.  Then, even if the log server’s private key was successfully stolen by a state-level attacker (and the attacker perhaps even compromises a minority of the monitor/auditor keys), the attacker will be unable to forge an STH signature that a Web client or anyone else will believe.

This would, in effect, convert each log server from yet another juicy central attack target into a strongest-link set (I like to use the term “cothority” or collective authority) with all the monitor and auditor servers watching it and contributing to its signatures.  Of course, the attacker still wins if he successfully compromises any single CA (or sub-CA) *and* any single “logging cothority” (i.e., any log server *and* a sufficient quorum of its followers).  But doing the latter becomes way, way harder if there’s enough size and diversity in each logging cothority.

How does this improve things for the Web client in Repressistan who's getting MITM attacked?  If the client is only looking at SCTs that are individually signed by a log server (and are in any case only a “promise to log soon” and not actual evidence that the cert has been logged), then unfortunately not much: the MITM attacker can still forge at least one SCT for each of its forged certs, and no one else learns because the MITM can keep the client’s view isolated from the rest of the world.

But say we enhance CT so clients can demand STHs *with* cert inclusion proofs from the web servers they talk to - as I suggested in the meeting today, and which I believe Ben Laurie mentioned is already in the works.  Then any Web client that does this will be proactively protected from MITM attacks involving faked, forked, or otherwise bad log entries.  And the client doesn’t have to compromise its privacy by gossiping with anyone.

Bryan

---

From: Ben Laurie <[email-masked]>
Date: Fri, 24 Jul 2015 11:09:23 +0000

On Thu, 23 Jul 2015 at 23:27 Bryan Ford <[email-masked]> wrote:

> *From: *Melinda Shore <[email-masked]>
> *Subject: **[Trans] Call for adoption, draft-linus-trans-gossip-ct*
> *Date: *July 23, 2015 at 2:03:24 PM GMT+2
> *To: *"[email-masked]" <[email-masked]>
>
>
> Hi, all:
>
> While the draft represents a fine start at defining a gossip mechanism, I
> would like to express serious reservations about the draft’s basic premise
> that a gossip mechanism is the best approach - or even an adequate approach
> - “to detect misbehavior by CT logs”, to quote the draft’s self-stated
> purpose.  As such, I have serious reservations about the WG adopting the
> draft, not because there’s anything wrong with the content of the draft per
> se but because gossip is simply not the right approach.
>
> First, the gossip approach creates severe privacy problems, which are
> already well-discussed so I won’t reiterate them.
>

Actually, I think you need to reiterate them, since we think that gossip as
proposed does _not_ create privacy problems.

>
> Second, the gossip approach can’t ensure that privacy-sensitive Web
> clients (who can’t or don’t want to reveal their whole browsing history to
> a Trusted Auditor) will ever actually be able “to detect misbehavior by CT
> logs”, if for example the misbehaving log’s private key is controlled by a
> MITM attacker between the Web client and the website the client thinks he
> is visiting.
>

The intent of CT is not to enable clients to detect such behaviour -
rather, it is to enable the system as a whole to detect it.

>
> Suppose, for example, it ever so happens that a single company ends up
> running both a log server and a [sub-]CA, and keeps both in the same
> poorly-protected safe.  If an attacker can steal those two private keys,
> then the attacker can silently MITM any CT-aware client all it wants, by
> producing all the [non-EV] certificates it needs with a valid SCT, valid
> STH inclusion proofs in a fake log, etc.
>

Chrome's policy would require the subversion of at least two logs to
achieve this, but for the sake of argument, I'll concede that.

>  The web client isn’t going to learn about the problem via gossip with the
> website because that’s the MITM attacker, and the client can’t gossip with
> anyone else without the serious privacy risk of trusting a single audit
> server with his entire browsing history.  If the “trusted audit server” is
> actually co-located with the client, then the audit server in turn can’t
> gossip with the rest of the world without creating the same privacy risk.
> Even if the client does voluntarily gossip with a remote trusted audit
> server, the MITM attacker - e.g., an ISP-level or state-level attacker -
> might simply block connections to all well-known audit servers.
>

This attack relies on a MitM that is sustained forever but indeed would
succeed. We accept that CT cannot defeat such an attack.

>
> Is it “too unlikely” that an attacker can compromise both a log server key
> and a CA key?  Even if some CT policy is established that a single company
> is never allowed to run both a log server and hold a [sub-]CA key, which
> might not be a bad idea, it doesn’t seem beyond reason that some
> state-level attackers are incapable of quietly exfiltrating (or just
> quietly subpoenaing) both a log server key and a CA key, and then they get
> the same, silent MITM power as they can get now.
>
> Thus, while CT does potentially “raise the bar” a bit by requiring a MITM
> attacker to steal both [any one] CA key and [any one] log server key, the
> set of all well-known log servers still just forms another new weakest-link
> security chain, just like the set of all CAs and sub-CAs form an old
> weakest-link security chain.  While “best of two weakest-link chains” is
> admittedly better than one weakest-link chain, it does not seem like the
> best we can do or the target we should be aiming for.
>
> I posted an E-mail last week suggesting an alternative approach, in which
> log servers would not individually sign their STHs but instead collectively
> sign them with the active participation of (a suitable quorum of) the
> auditors and/or monitors watching their logs.  But I got no response to
> that, so I’d like to try again.
>
> In short: the log server would propose log entries, but the auditors
> and/or monitors contribute to the STH signature, only after performing at
> least the “auditing” function of verifying that the log server is behaving
> like a correct log server.  In particular, all participants could
> proactively verify that the log server never forks or reverts the log,
> never signs something syntactically invalid or with a wildly-incorrect
> timestamp (say +/- 24 hours), etc.  Then, even if the log server’s private
> key was successfully stolen by a state-level attacker (and the attacker
> perhaps even compromises a minority of the monitor/auditor keys), the
> attacker will be unable to forge an STH signature that a Web client or
> anyone else will believe.
>
> This would, in effect, convert each log server from yet another juicy
> central attack target into a strongest-link set (I like to use the term
> “cothority” or collective authority) with all the monitor and auditor
> servers watching it and contributing to its signatures.  Of course, the
> attacker still wins if he successfully compromises any single CA (or
> sub-CA) *and* any single “logging cothority” (i.e., any log server *and* a
> sufficient quorum of its followers).  But doing the latter becomes way, way
> harder if there’s enough size and diversity in each logging cothority.
>
> How does this improve things for the Web client in Repressistan who's
> getting MITM attacked?  If the client is only looking at SCTs that are
> individually signed by a log server (and are in any case only a “promise to
> log soon” and not actual evidence that the cert has been logged), then
> unfortunately not much: the MITM attacker can still forge at least one SCT
> for each of its forged certs, and no one else learns because the MITM can
> keep the client’s view isolated from the rest of the world.
>
> But say we enhance CT so clients can demand STHs *with* cert inclusion
> proofs from the web servers they talk to - as I suggested in the meeting
> today, and which I believe Ben Laurie mentioned is already in the works.
> Then any Web client that does this will be proactively protected from MITM
> attacks involving faked, forked, or otherwise bad log entries.  And the
> client doesn’t have to compromise its privacy by gossiping with anyone.
>

Two points here:

1. Is this any different to requiring n SCTs from different logs for each
certificate (other than the inclusion proof part, which I address below)?

2. Our original design for CT did indeed have certs served along with an
STH and an inclusion proof. Unfortunately, CAs categorically rejected this
approach because of the latency it introduced in the certificate issuance
process. Personally, I think it would be a better approach. Now CAs are
more accepting of CT, perhaps it would be worth revisiting the question
with them?

>
> Bryan
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Rob Stradling <[email-masked]>
Date: Fri, 24 Jul 2015 14:09:04 +0100

On 24/07/15 12:09, Ben Laurie wrote:
<snip>
>     But say we enhance CT so clients can demand STHs *with* cert
>     inclusion proofs from the web servers they talk to - as I suggested
>     in the meeting today, and which I believe Ben Laurie mentioned is
>     already in the works.  Then any Web client that does this will be
>     proactively protected from MITM attacks involving faked, forked, or
>     otherwise bad log entries.  And the client doesn’t have to
>     compromise its privacy by gossiping with anyone.
<snip>
> STH and an inclusion proof. Unfortunately, CAs categorically rejected
> this approach because of the latency it introduced in the certificate
> issuance process. Personally, I think it would be a better approach. Now
> CAs are more accepting of CT, perhaps it would be worth revisiting the
> question with them?

I think we need to make this approach available as an option.  We should 
retain the lower-latency option (i.e. SCTs) too though.

TRAC ticket 10 already aims to do this.

DV certs are typically validated and issued quickly.  For EV certs and 
name-constrained Sub-CA certs, the process can take days/weeks/months, 
so added latency in issuance may be less of a concern.

When OCSP Stapling and/or the CT TLS extension are used to convey "CT 
objects" to TLS clients, the TLS server could send SCTs for the first 
few hours, then switch to sending inclusion proofs / STHs once the log 
has generated them.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Tom Ritter <[email-masked]>
Date: Fri, 24 Jul 2015 09:10:40 -0500

I'm an author, so +1 to adopt?

I reiterate Ben's point that we don't believe this draft has privacy
problems.  (Well you can _opt in_ to having privacy problems by using
a trusted auditor, which does leak your browsing history, but that's
not the expected use case for most clients by far.  The other two
approaches are designed to be privacy preserving.)

On 24 July 2015 at 08:09, Rob Stradling <[email-masked]> wrote:
> name-constrained Sub-CA certs, the process can take days/weeks/months, so
> added latency in issuance may be less of a concern.
>
> objects" to TLS clients, the TLS server could send SCTs for the first few
> hours, then switch to sending inclusion proofs / STHs once the log has
> generated them.

I like it. I like the OCSP approach better than Certs though, because
it eliminates the requirement of "private-enough DNS" to retrieve
Inclusion Proofs in STH Pollination, and lets more privacy-concerned
clients participate in STH Pollination.  (Because an Inclusion Proof
to a STH in a cert would be a very old STH, which we could not gossip
because (over time) that STH will become rarer and rarer and probably
lead to a fingerprint.

-tom