On Thu, Dec 15, 2005 at 05:06:15AM -0500, Nick Mathewson wrote: > > Roger, the current Tor experience is already terrible as it is. > > It would be far more urgent to implement quality metrics > > (throttle abusers and favor people who donate lots of bandwidth), > > and only then to limit the entry barreers (Tor plugin for > > browsers, simple one-click installation, NAT penetration, whatever) to > > draw in more users. Injecting chaff will only drive the network > > into unusability for interactive use, so only abusers with robots > > are left. Please don't go there. > > Hi, Eugen. > > I'm sorry you find the experience terrible. We've been working more > than full time for several years now to try to make it otherwise > without sacrificing performance or security. I'm an unusually patient user. I can tolerate delays, and DNS lookup failures, and periods where the exit node is b0rked and I have to wait for a new circuit. I don't like it, but I usually can live through it. An average user tries it once, and gives it up. (This is not a hyperbole. Try it with a statistically significant set of naive users). Henceforth, his association chain is Tor=dog slow and/or unreliable. This is not a good association chain. > The only way I can see us building any such system into Tor is if it > could be shown to significantly resist fingerprinting or end-to-end > correlation attacks without degrading performance significantly. I see Tor primarily as a) hard to block (since dynamic and geographically diverse) and hard to sue (since noncommercial) list of anonymizing proxies b) something that increases the opaque (encrypted) traffic background. As such I would like to see more users, and a larger network. The only way to draw more users is provide a better experience, and market it. Adding crap nodes to degrade the network is a valid attack mode, so if the protocol can't handle it now, it should in the future. > Our current focus for increased performance is to get more servers by > encouraging more users to run servers. After all, more users without It should be not just servers. It should be *good-quality* servers. Each client should be also a server by default, and the protocol should be able to tell the crap nodes from the good ones, and route accordingly. Periodically probing exit nodes and benchmarking them is possible, no? > more servers makes performance worse. To do this, we must first work > on the network's architecture so that it can scale to tens of > thousands of relays without collapsing. We're doing this now. Good point. > Second, we need to make it easier to run a server, and create > incentives to do so. This is an active area of research. Can you make all clients servers by default, and use un-NATed servers for NAT penetration? > (It's not easy to give contributors higher priority, and the reasons > why have been hashed over before. The issue is how to give good users > without making it easy for an attacker to isolate their by its higher > priority. We're working on this, but it isn't easy. If there were an > easy and secure way, we would have built it, I promise.) Most legal attack modes are completely thwarted by 1-2 levels of traffic indirection, even if it's cleartext traffic. The TLAs can already most likely listen in, whether we like it, or not. Sure there is a tradeoff between security and usability. But usability results in more users and more servers, so the network becomes harder to attack. > If we can assume that the attacker is too idiotic to carry out the > attack, then of course any system you name is secure against any > attack you name. But if one of these "knuckledraggers" knows enough > to ask somebody who reads the literature, or if they announce that > they care vocally enough to contract a commercial provider to > implement simple traffic correlation techniques, they will fare worse. The point is that this would require international cooperation. The network is distributed across legal compartments. Tapping just one compartment isn't enough. Claiming copyright infringement is insufficient incentive. > After all, most sub-TLA police agencies do not build their own > surveillance tools: they buy them off the shelf. Sub-TLAs can't cooperate internationally, across several countries. (This is an educated guess, of course -- if anyone has insider knowledge, feel free to correct me here.) > I agree with Roger that the best defenses we know now against this > kind of attack are to increase the total volume of traffic (by growing > the network to handle that traffic), and to split entry and exit > across locations that are unlikely to be compromised by the same > attacker. Yep. > Once again, I'm very sorry that you are unhappy with Tor performance. > We are aware that it is not as fast as many people would like, and we > are aware that improving it would be good. Please feel free to > contribute any patches you like, and to encourage your friends who Um, you don't want any patches from *me* (and most of my friends who would fit the bill unfortunately are too busy working the $dayjob). Donating server space and providing commercial incentive for others to do so is however a plan. We'll see how it goes. > might know how to program to do so. -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
Attachment:
signature.asc
Description: Digital signature