[tor-dev] Desired exit node diversity

Paul Syverson paul.syverson at nrl.navy.mil
Wed Sep 23 12:44:15 UTC 2015


On Wed, Sep 23, 2015 at 11:34:54AM +0000, Virgil Griffith wrote:
> > because "the right distribution" is a function of which adversary you're
> > considering, and once you consider k adversaries at once, no single
> > distribution will be optimal for all of them.)
> 

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). Also all fast-relay operators (which here is the same
as all relay operators) don't merely get a T shirt but a pony wearing
a T shirt. Put differently, I need your ceteris paribus clause spelled
out a lot more so I know what things I can assume in this ideal world
and where I have to live with the actual world (to the extent that
we even know what that looks like).

> Granted.  But since we're speaking idealizations, I say take that the
> expected-value over the distributions weighted by the probability of each
> adversary.  In application this would be a distribution that although
> unlikely to be optimal against any specific adversary, it's has robust
> hardness across a wide variety of adversaries.

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.

> 
> Or, if that distribution is unclear, pick the distribution of exit-relay
> with the highest minimum hardness.  This reminds me of the average-entropy
> vs min-entropy question for quantifying anonymity.  I'd be content with
> either solution, and in regards to Roster I'm not sure the difference will
> matter much.  I am simply asking the more knowledgeable for their opinion
> and recommendation.  Is there one?

I don't think you can meaningfully do this. It's going to be based on
a particularly bad closed-world assumption (worse than the one
underlying so many website fingerprinting analyses). You would have to
assume that you know all the adversaries that all the user types have
and, if you are averaging in some way, then also the average amount of
exit utilization that each user type represents. Ignore the technical
impossibility of doing this in a privacy-safe way and then ignore the
technical impossibility of doing this in a privacy-unsafe way. 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.)

aloha,
Paul

> 
> -V
> 
> 
> 
> On Wed, Sep 23, 2015 at 2:47 PM Roger Dingledine <arma at mit.edu> wrote:
> 
> > On Wed, Sep 23, 2015 at 06:26:47AM +0000, Yawning Angel wrote:
> > > On Wed, 23 Sep 2015 06:18:58 +0000
> > > Virgil Griffith <i at virgil.gr> wrote:
> > > > * Would the number of exit nodes constitute exactly 1/3 of all Tor
> > > > nodes? Would the total exit node bandwidth constitute 1/3 of all Tor
> > > > bandwidth?
> > >
> > > No. There needs to be more interior bandwidth than externally facing
> > > bandwidth since not all Tor traffic traverses through an Exit
> > > (Directory queries, anything to do with HSes).
> > >
> > > The total Exit bandwidth required is always <= the total amount of Guard
> > > + Bridge bandwidth, but I do not have HS utilization or Directory query
> > > overhead figures to give an accurate representation of how much less.
> >
> > On the flip side, in *my* idealized Tor network, all of the relays are
> > exit relays.
> >
> > If only 1/3 of all Tor relays are exit relays, then the diversity of
> > possible exit points is much lower than if you could exit from all the
> > relays. That lack of diversity would mean that it's easier for a relay
> > adversary to operate or compromise relays to attack traffic, and it's
> > easier for a network adversary to see more of the network than we'd like.
> >
> > (In an idealized Tor network, the claim about the network adversary
> > might not actually be true. If you have exit relays in just the right
> > locations, and capacity is infinite compared to demand, then the network
> > adversary will learn the same amount whether the other relays are exit
> > relays are not. But I think it is a stronger assumption to assume that we
> > have exactly the right distribution of exit relay locations -- especially
> > because "the right distribution" is a function of which adversary you're
> > considering, and once you consider k adversaries at once, no single
> > distribution will be optimal for all of them.)
> >
> > --Roger
> >
> > _______________________________________________
> > tor-dev mailing list
> > tor-dev at lists.torproject.org
> > 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



More information about the tor-dev mailing list