> 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. 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
