On Thu, 23 Jul 2015 at 23:27 Bryan Ford <[email protected]> wrote:
> *From: *Melinda Shore <[email protected]> > *Subject: **[Trans] Call for adoption, draft-linus-trans-gossip-ct* > *Date: *July 23, 2015 at 2:03:24 PM GMT+2 > *To: *"[email protected]" <[email protected]> > > > 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. > 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 protected] > https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
