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

[Bryan Ford <[e-mail]>]

Sorry for the slow followup, I wasn’t able to keep up with the lists since the IETF meeting...

> On Jul 24, 2015, at 1:09 PM, Ben Laurie <[e-mail]> wrote:
> On Thu, 23 Jul 2015 at 23:27 Bryan Ford <[e-mail] <mailto:[e-mail]>> wrote:
>> From: Melinda Shore <[e-mail] <mailto:[e-mail]>>
>> Subject: [Trans] Call for adoption, draft-linus-trans-gossip-ct
>> Date: July 23, 2015 at 2:03:24 PM GMT+2
>> To: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> 
>> 
>> Hi, all:
>> 
>> This is a call for adoption of
>> http://datatracker.ietf.org/doc/draft-linus-trans-gossip-ct/ <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.

It creates new privacy problems by requiring the client (browser user) to “opt out” of web browsing privacy in order to gain any security benefit.  Either the user hands over all his browsing history to a remote “trusted auditor”, thereby opting out of privacy; or else the user remains fully vulnerable to the same kind of (potentially extended) MITM attacks that motivated CT in the first place.
 
> 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.

Could you explain how “the system as a whole” detects such misbehavior in the case of the state/ISP-level MITM attacker scenario?  

As I see it, if the client/browser doesn’t opt-out of privacy by gossiping his browsing history with a trusted auditor, then the client’s *only* connection to the rest of the world, i.e., “the system as a whole”, is through the “web server”, which may well be the same kind of MITM attackers that have been known to subvert the CA system.  The client never gets to communicate to the rest of the system - i.e., the legitimate CT log servers, auditors, or monitors - and so the client never gets the opportunity to “compare notes” with the rest of the system.  And the rest of the system (the legitimate log servers, auditors, and monitors) never have the opportunity to learn from the client that the client saw a MITM-attacked, forged set of CA certs, STHs, and SCTs.

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

I thought you were requiring CAs to have multiple SCTs only for EV certificates, no?  What if the attacker is happy to MITM attack the user with a non-EV certificate and forego showing the user the “green bar”?  Are you assuming that users will stop using the connection if they don’t see the green bar?

Or are you saying (contrary to my prior understanding) that Chrome requires *all* CT certs to have multiple SCTs signed by different log servers?
 
>  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. 

But isn’t that precisely what happened in the prior COMODO and DigiNotar cases, where the MITM attacks were detected only when a few more security-conscious users compared the certificates they were seeing against what the rest of the world was seeing through nonstandard “side-channels”?  Isn’t that 

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

Semantically, no different, but how large many SCTs do you think is practical to require to be attached to each cert?  Two, three?  Ten?  A hundred?  How big is each SCT?  

With the multi-SCT approach, the amount of bandwidth consumed during TLS negotiation with every CT-supporting website increases linearly with n.  With the scalable multisignature approach, n can increase to arbitrarily large size - a hundred, a thousand if needed - e.g., including all the public auditors, monitors, etc. - without any increase in the size of certificates, number of SCTs attached, or ultimately the bandwidth/latency overhead during TLS negotiation.

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

Agreed, that would be great.

Bryan

>  
> 
> Bryan
> _______________________________________________
> Trans mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/trans <https://www.ietf.org/mailman/listinfo/trans>