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
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev