Re: [Trans] draft-linus-trans-gossip-ct-01: gossiping STHs

[Tom Ritter <[e-mail]>]

On 24 March 2015 at 16:48, Ben Laurie <[e-mail]> 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