Like Tails' friends, foes, and neutral HTP pools… "any member in a one pool should be unlikely to share logs (or other
identifying data),
or to agree to send fake time information, with a member from the the
other pools"
This may be heretical, but I always thought this motivation above is a plausible reason to have more "non-activist" types running Tor relays---we just have too many friends, a few foes would be a welcome addition!
-V
On Wed, Oct 28, 2015 at 1:11 PM Tim Wilson-Brown - teor teor2345@gmail.com wrote:
On 28 Oct 2015, at 14:31, Virgil Griffith i@virgil.gr wrote:
Instead of WOT, it seems more desirable, and better fit diversity, to
have both your best friends and worst enemies on the same circuit. Ergo, minimizing chance of collaboration.
Like Tails' friends, foes, and neutral HTP pools… "any member in a one pool should be unlikely to share logs (or other identifying data), or to agree to send fake time information, with a member from the the other pools" https://tails.boum.org/contribute/design/Time_syncing/#index4h2 < https://tails.boum.org/contribute/design/Time_syncing/#index4h2%3E
T
-V On Mon, 26 Oct 2015 at 01:30 grarpamp <grarpamp@gmail.com <mailto:
grarpamp@gmail.com>> wrote:
On Wed, Sep 23, 2015 at 8:44 AM, tor-dev had:
I agree with Roger that ideally all relays can be exits (and since we're being ideal, we'll assume that 'exit' means to every port). And the network location distribution of relays by bandwidth is proportional to both the client destination selection over time and general Internet traffic over time, which match each other since we're being ideal, and also matter since we're using an ideal trust-aware
path
selection algorithm. And network wide route selection is such that there is no congestion (generalizing Roger's assumption of infinite exit capacity).
Guessing that... assuming you can ship and calculate all the relay data / DHT / weights / KEX / circuits / preferences without bogging down your network or cpu...
More relays being exits yields higher maximum possible path diversity. More relays being exits yields higher potential aggregate throughput between the network and clearnet. More exits yields broader more complete location overlay relavent to users (more relays yields more guards), datacenteres, and clearnet services (though there's as yet no attempt to exit near a service unless done manually).
However when subject to global passive adversary tapping lots of the fiber, and you turn up more relays as exits (which are also non-exit relays by nature), you're adding lots more unused bandwidth over the same current consumption, leading to lots of unused quiet portions of the network. Which seems a greater potential for the adversary to "look, user just shot a unique traffic pattern completely through the quiet zone, gotcha". Whereas when the network links are full with clocked traffic (and fill traffic if there would otherwise be slack space) that observation attack is hardly as possible, to relavently impossible.
If true, it seems to me adding more [non] exits should be pegged to some metrics and solicited on need / planning rather than turning up 6000 exits all at once.
In our ongoing work on trust-aware path selection, we assume a trust distribution that will be the default used by a Tor client if another distribution is not specified. (Most users will not have a reasoned understanding of who they actually need to worry most about, and even if they somehow got that right would not have a good handle how that adversary's resources are distributed.) We call this adversary "The Man", who is equally likely to be everywhere (each AS) on the network. For relay adversaries, we assume that standing up and running a relay has costs so weight a bit to make relays that have been around a long time slightly more likely to be trusted.
tor-relays had talk of individual humans keyparty signing their relays and including that WOT along with other trust and meta metrics in the consensus or other queryable datastore that could be used by the user to select preferred relay sets in whichever sensible or silly ways suited them.
An adversary standing up relays has costs. Adversaries standing their human agents in public, even if their undercover is maintained, has additional costs and risks.
You would then be faced with the political nightmare of issuing default policies that tells users they should route with a weighting that says country foo has an x percent chance of being your adversary, but country bar has a y percent chance. (Likewise also have similar statements that substitute 'large multinational corp.', 'major criminal organization', 'specific big government agency that is getting all the press lately' etc. for "country" in the last sentence.)
======== In a sense this is like the original 'valid' flag, which you got by mailing me and having me manually approve your relay (and without which you would never be used as the entry or exit point in a circuit). Periodically I wonder if we should go back to a design like that, where users won't pick exit relays that don't have the "socially connected" badge. Then I opt against wanting it, since I worry that we'd lose exactly the kind of diversity we need most, by cutting out the relays whose operators we don't know.
But both sides of that are just guessing. Let's find out!
These type of things may be better suited to a system where the users contribute their research and knowledge about the network into the network metadata db, and the users can query it to make their own decisions, follow other users prebuilt selection templates, or stick with the provided defaults. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org mailto:tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev <
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev%3E
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk