On Mon, Feb 17, 2020 at 11:53:28AM +1000, teor wrote:

...

On 13 Feb 2020, at 22:05, zwiebeln <zwiebeln@online.de> wrote:

depended on a network that is 21 percent controlled by a single person that you don't know?

I agree that it's not best. But I'll turn it around, and point out that many systems (e.g. most VPNs) are centralized, that is, the number is 100 percent. (You might turn it back around and say that VPNs are companies and you have an agreement with them so nothing will go wrong. That's a good point too, though that trust should only go so far. It's not clear to me which one is the shakier argument. :)

"Let's encourage people to run more relays." [...] ultimately, if we doubled tor's exit bandwidth, this issue would go away. That's the best solution to this problem.

Agreed. Though, hm. In the sense that Tor's security comes down to probabilities, it's not obvious that 20% of the network is much worse than 10% of the network. Let's say there is some activity which you do periodically, and you're worried that some relay-running adversary will be in a position to observe your traffic and learn about your activity ("watch an exit stream as it leaves the Tor network", "be chosen as your guard" etc). The actual probabilities depend on the specific attack we're talking about, but I can imagine some situations where the 20% relay operator is twice as likely to be in a position to do the attack compared to the 10% relay operator. So for recurring behavior, that might be equivalent to saying that the 10% relay operator takes twice as long to succeed at the attack compared to the 20% relay operator. That multiplier doesn't seem like a substantial (qualitative) difference. Or said another way, if I'm not comfortable with the 20% attacker, I shouldn't be much more comfortable with the 10% attacker. This analysis reminds me of the discussion from the "Users Get Routed" paper: https://www.freehaven.net/anonbib/#ccs2013-usersrouted https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramete... where the aim is to choose the best parameters to slow down probabilistic attacks for as long as possible. Centralization definitely makes me uncomfortable, but as you say, we also have to worry about centralization of where traffic goes between relays, centralization of undersea cables, centralization inside countries, etc. It's times like this where I wish the world knew how to do mixing with streams. That is, there is a whole field out there on how to build stronger anonymity designs, based on mix-nets, but nobody knows how to do that safely when users generate flows of messages rather than just a single message.

I'll also ask our new Network Health team to consider the risk of large operators and large ASes. Hopefully they can recommend some changes to the bandwidth authorities (or sbws maintainers).

I definitely think there is a role to be played here by improved bandwidth scanners. I'm thinking of the tor-relay thread about the quintex relays: https://lists.torproject.org/pipermail/tor-relays/2020-January/018044.html where they're slowly losing their consensus weights, despite having plenty of capacity, and nobody understands why. Making sure that people who want to contribute a lot of bandwidth can actually do it is really important. So I do continue to think that accurate consensus weights are a huge piece of usefully moving forward here, which is why I told GeKo that in my opinion that's the #1 priority item for the network health team to get a handle on. And then, once we have some confidence in our bandwidth weights, that's a great point to start exploring reducing centralization -- along several axes, not just relay operator concentration. But even then, we would want to do it carefully. For example, let's say we declare that no relay family should get more than 10% of the total consensus weight for any relay role (guard, exit, etc). By adopting a policy like that, we could accidentally *increase* the total weight that actual bad relays receive, thus providing yet another incentive for attackers to assign their families incorrectly. See also the tickets on whether MyFamily is a harmful idea, because it pulls traffic away from honest relay operators and sends it to dishonest ones: https://bugs.torproject.org/6676 https://bugs.torproject.org/15060 So in summary: (a) yes we should get more relays and more capacity, and (b) yes it is super important for us to get better at making the consensus weights accurate and predictable and well-understood, but also (c) there are a bunch of interconnected reasons why these two steps are important to do, and I think "help relay operators contribute and feel good about it" is much more urgent than, and ultimately a more productive fix, for "omg one family is currently 17% of the network." Thanks! --Roger

There is only a small path between moderation and censorship – to get my message released after four days is close to… Your answer Theo is rather technical and doesn't apply really on the underlying question: „Would you place your secrets or in worst case make your life depended on a network that is 21 percent controlled by a single person that you don't know?“ Your assumption: „But ultimately, if we doubled tor's exit bandwidth, this issue would go away. That's the best solution to this problem.“ - is wrong. The Exit only https://metrics.torproject.org/bandwidth-flags.html?start=2017-11-19&end=202... has more than doubled in the last two years – while the exit probability of this single person decupled. „Perhaps you could run more relays?“ - I am with the project now for more than three years an do run a exit probability somewhere close to 2 percent, that i don't like to increase, because i think it is a more than healthy fraction for a singe person – so why do you insinuate, my question is not in a „good faith“? I hope more people do come on board of this discussion now! Paul On 17.02.20 02:53, teor wrote:

Hi,

A quick reminder to everyone on this list: this list is moderated. Please keep your replies helpful and on topic.

...

On 13 Feb 2020, at 22:05, zwiebeln <zwiebeln@online.de> wrote:

depended on a network that is 21 percent controlled by a single person that you don't know?

https://nusenu.github.io/OrNetStats/allexitfamilies

I think we should start an open debate on that fact, best ending up with giving some recommendations. I am sure that question is relevant to torproject.org as well.

We've had similar questions a few times on this list.

The most common answer is:

"Let's encourage people to run more relays."

Perhaps you could run more relays? Or ask for help improving your consensus weight?

The operator of those relays is on this list, asks questions, and responds to emails. They've been helpful in the past.

So please ask questions in a way that assumes good faith: https://en.wikipedia.org/wiki/Good_faith You'll be more likely to get a helpful answer.

It's also important to keep network risks in perspective: * 99% of relays run Linux, and a significant number of those are Debian (or Ubuntu, or other derivatives) https://metrics.torproject.org/platforms.html * there is 1 bridge authority (100%), 6 bandwidth authorities (17%), and 9 directory authorities (11%) * the consensus algorithm tries to limit the risks of one directory authority influencing large parts of the tor network, and manual bridge distribution limits the impact of the bridge authority * the largest ASes have: * 23% of guards and 22% of middles (Hetzner) * 16% of guards and 12% of middles (OVH) * 10% if guards (Online) * 20% of exits (J P McQ) https://metrics.torproject.org/rs.html#aggregate/as

So it's not really helpful to single out a particular operator or network.

As far as I recall, the most widespread security issue that's happened to the network was the Debian OpenSSL bug: https://www.debian.org/security/key-rollover/

There are all kinds of risks that happen when a large part of the network has a similar setup: * relay operator compromise * AS operator compromise * platform compromise * observation of traffic via common network infrastructure * network availability * poor performance * poor bandwidth weights

Tor relay consensus weights are determined by the bandwidth authorities, so we might also be seeing: * a bug in the bandwidth authority software (sbws or Torflow), or * a majority of bandwidth authorities configured in a way that concentrates bandwidth in particular areas.

I've opened a ticket in sbws to track this issue: https://trac.torproject.org/projects/tor/ticket/33350 (Torflow is unmaintained, and we're planning to completely replace it with sbws in 2020 or 2021.)

I'll also ask our new Network Health team to consider the risk of large operators and large ASes. Hopefully they can recommend some changes to the bandwidth authorities (or sbws maintainers).

But ultimately, if we doubled tor's exit bandwidth, this issue would go away. That's the best solution to this problem.

Again, please keep your replies helpful and on topic.

T

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays