[tor-dev] [tor-talk] Desired exit node diversity

Wed Oct 28 05:21:47 UTC 2015

> 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 at gmail.com>
wrote:

>
> > On 28 Oct 2015, at 14:31, Virgil Griffith <i at 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>
>
> T
>
> >
> > -V
> > On Mon, 26 Oct 2015 at 01:30 grarpamp <grarpamp at gmail.com <mailto:
> grarpamp at 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 at lists.torproject.org <mailto:tor-dev at lists.torproject.org>
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev <
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev>
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at 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 at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151028/a27cb2c3/attachment.html>