On 24 March 2015 at 16:48, Ben Laurie <[email protected]> wrote: > If TLS clients and servers send each other STHs, then realistically, there > is no privacy issue: everyone has all STHs.
I had thought about this for a while, I'm going to outline my train of thought as briefly as I can, but it'll still be a tad long. How do I (TLS Client) get STH's? Few ideas: - Request them from logs from a given SCT (and logs learn my browsing habits, that's bad) - Request the latest SCT-head from logs (less privacy-worrying, but still - I don't like the idea of my browser calling out to random third parties so they can attempt to track me and learn my online habits) - My browser proxies latest SCT-head in update checks?? - Servers send me STH's (and Inclusion proofs?) with an SCT - Servers proxy STH (and inclusion proof) requests for a client Proxying is not a fully deployable mechanism. Not all server operators are willing to allow outbound connections from servers, you have to be whitelist log addresses to avoid becoming a full proxy. Even if I did get STH's this way there is still a problem. So I'm ruling that out. A STH is minorly useful, in that it's a signed statement we may catch a log having lied about. But without an inclusion proof for a SCT, a STH is just a dead piece of data the client holds and then gives to someone in the hope it's useful later. Assume a client gets an inclusion proof along with an STH. This is one more component of the lie, but still, is just dead data that does not significantly help the client. Are STH's (by themselves) even useful for detecting misissuance? No. If we assume a log will misbehave we have to assume a log will try to cover up it's misbehavior. This means an SCT will have a valid STH associated, and that a log will be willing to continue a 'fork' (including all other SCTs, so differing in only a single node) essentially forever in the hope of not getting caught. So assume the STH 'branch' extends from the point of misissuance until present day. So we need consistency proofs. An STH (even on the misissuance branch) is not useful without linking that STH to another STH. There is value in linking STHs with consistency proofs - if one cannot get a consistency proof between two STH's _then_ you've detected log misbehavior. But how does someone get consistency proofs? They can only come from the log. So either the client attempts to resolve consistency proofs itself (this brings us back to the original problem of asking a log or proxies, so we rule this out) or the client passes on STH's for someone else to resolve consistency proofs. Of note: if I've been attacked, and have a STH on a misissuance branch I will _never_ just 'happen' to get a consistency proof that shows it's an attack. I'll always have an STH hanging out I can't connect, but also can't be certain _isn't_ connected. I can _only_ detect misissuance by _actively_ querying a log for a consistency proof between by misissuance STH and a valid STH. Another issue with STH's is (at present) they can be uniquely identifiable. A log can (as I read 6962) create a new STH for every SCT they create. This is unrealistic, and it's not the bedrock of my argument, but it's worth noting. Regardless of that loophole, a STH is somewhat identifiable (and potentially a tracking mechanism) depending on the algorithm they are given. Design me an algorithm, and you can find some amount of privacy leak in it. (For example, a SCT can reveal last online time. Or, in conjunction with other STH's, it can reveal some indication of what sites you visited.) Another independent component: I assume a client does _not_ have a trusted auditor, because said auditor is basically some third party you're going to send your SCT (aka browsing history) to. And who is doing to run the default auditors? Privacy problem, the same as OCSP lookups. (nb. a client can obviously opt-in to a trust auditor) In some cases I note "something can only come from a log" but it could probably some from an auditor. But the problem is the same: who is this auditor/log we're willing to release data to by default? Gossiping STHs seems natural, but I could not arrive at a way to connect all the data in a privacy preserving manner. If we follow strict privacy protection this is what I arrived at: A) Clients get STH's (from servers I must conclude) but don't care about them. (Or they get STH's + Inclusion Proofs and validate the proof) B) Clients pass the STH back to someone (which must be the server it got it from. (Or a opt-in trusted auditor)) C) An auditor collects the STHs from somewhere (must be servers following from (B)) and retrieves consistency proofs between them. Misissuance is detected at (C). Because the client itself does not do anything with a STH, and because a SCT will always resolve to an STH, it seemed like it would be both simpler and bandwidth reduction to just cut it out. -tom _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
