On 6/18/15, grarpamp wrote:

On Thu, Jun 18, 2015 at 12:51 AM, Roger Dingledine wrote:

...

but it sure looks like another case of somebody not understanding the research field, and thinking that solving the traffic confirmation attack is easy, without actually thinking through the engineering side, the scaling side, or the statistics side.

There's certainly no easy solution to all problems. Though there could be value in those that put more odds in your favor, even though they do not yield 100% solution or protection.

If you rarely tx but then emit something [unique or timely] that pops out at some [rare] destination, you're done for. I think we've seen posts from some people who slow crawl the web 24x7 when their client is running just to add cover at their end for their interspersed real web activity.

For a potentially useful project to many: software to crawl and cache popular news sites into a content addressed darknet/ localnet cache, so that folks can browse the daily news without using exit nodes. Trust network above that is a separate task entirely. For bonus points, have the content addressing be in git.

...

But even full scale padding, ignoring the practical side of how to get a Tor network that can afford to waste so much bandwidth

Waste is an incorrect, negative term for designed in padding (fixed set of lengths) or fill (empty links) or chaff (ratio) or whatever this is.

A design where fill traffic gets out of the way when real data is being sent might have periods of congestion or underutilization of the link depending on the distance in hops the fill is managed over, and the speed of the sensing and feedback controls. Seems that might need to be as fast as you could initiate a first packet across, unless you inhibit that packet until ready.

Just as the disadvantages of HFT (high frequency trading) can be handled with a trade-window model (all trades are batched into a 1s, or 10s or whatever window to be resolved by the exchange at the end of each window), "inhibit packet until ready" makes me think this might be applied to Tor networks - specifying a "relatively high" minimum latency for new session initiation. But again, it's the type of problem/solution potential which needs genuine analysis to know if there's going to be a non-trivial privacy enhancing benefit. I can only make assumptions sorry.

...

doesn't provide protection in the face of active attacks where you induce a gap on one side and then observe the gap on the other side. And it might even be the case that these gaps happen naturally by themselves, due to network congestion and so on, so maybe passive observers will be winners even against a design that does full padding.

I've said that fill seems useful against passives, not actives. However a design may actually be possible such that any disturbance or deficiency in fill might be possible to make up from other sources.

E.g. your entry point (e.g. ISP) introduces "random peak bandwidth drops/ latency holes" and when the ISP's incoming networks fail to keep up their side of this same bargain, the link deteriorates completely. This implies an ISP who is on the side of the users, at this point a rare thing (if it exists at all).

In other words, if I knock you off the net, the remaining path your data would have taken to your endpoint will still be filled so as not to expose the far end as being tied to you (if the fill management scope of the network is finer grained than just the end nodes negotiating end-to-end with each other (ie: I think the entire net will need to negotiate their own mesh of fill peers as an underlying management layer, with possible cues from above)). You get knocked off, your former peers sense this and recalc their fill sources and sinks.

This 'feels' like it has potential. Except I think it presumes that at least your starting node(s) (eg ISP) are not actively adversarial to you - but are we assuming this anyway with current Tor? (Sorry for my ignorance.)

...

tl;dr the whole premise of this person's blog post is flawed, since their design likely does not work as they think it does.

While someone's design may be insufficient to solve some problem, it does add value in the form of talk of possible solutions and trialing them. Thereby others can try different / related avenues to a solution.

A thought I've pondered for a couple years now - and now in this context, let's say my geographic neighbour and I each have an ISP uplink, and wireless connection between one another. If my "underlying fill traffic network" (physical/PHY layer, at least from my perspective as an end user) can somehow include the private connection between my neighbour and I, and if the ISP actively targets one of us and crimps the connection, and then the neighbour similarly ("pro-actively") crimps his connection in 'almost parallel', could this provide some level of plausible deniability of the exit-node traffic being correlated to either one of us? (Expand algorithmically to more than one neighbour.) Is it worth beginning an "ISP end user fill traffic protocols best practices RFC" for those ISPs who genuinely want to do the right thing, legally as well as by their customers? Or is the multiplexing of the last-node-before-the-home (eg the ISP's DSLAM ADSL modem bank) simply not capable of such things? I guess what I'm asking: what's the ideal way to roll out community-/state- wide internet networking infrastructure, from a respect-the-uesrs-privacy perspective?

...

For background see e.g. http://freehaven.net/anonbib/#danezis:pet2004

...

This is a great area for further research: http://freehaven.net/anonbib/#ShWa-Timing06 http://freehaven.net/anonbib/#active-pet2010

I don't mean that Tor specifically needs to investigate or implement fill, but that since the research area is probably not complete, and that no operational net is trying it, it's worth continued work.

Let's keep asking the questions and attempting to answer them, and see if we can't eliminate the benefit logically (without having to wait for a high fallutin' acamedic paper). Eg 1: there are fibre-optic "DSLAMs" (modem banks? - dunno the term sorry), which simply broadcast all client downlinks to all end-points, and it's only the end point modems which "do the right thing" and ignore their neighbour's traffic. In this scenario, there may only be 2Gbps of bandwidth shared amongst 1000 homes. If all homes jump on the "maximize fill traffic" bandwagon, each will get at most a fixed 2Mbps link - fast by many standards, but nowhere near what would be achieved in a forget-about-privacy scenario. And then, what should happen at the ISP level? What sort of protocols would make sense for ISP interconnection - to other ISPs, to upstream ISP/ national backhaul, to international (usually expensive) links? Eg 2: ADSL DSLAM - can this device scale reasonably to all homes connected to this DSLAM? In either scenario, do we need to start thinking new equipment, or just new protocols - since fill-traffic is a type of protocol and as we've read, proposals have been made for ethernet-level fill traffic.

If anyone knows a good list that does or would serve as home for such work, please say so as I'm unaware of any.

Clear thinking, ask the hard questions, gather answers, write it up in an RFC or draft "paper", post for review, and it'll eventually get archived at the usual places - even if the answers are "we can't do X and Y for reasons A and B" - these would be very useful answers.