[tor-dev] Setting NumEntryGuards=2

[Mike Perry]

George Kadianakis:
> David Goulet <dgoulet at torproject.org> writes:
> > On 22 Mar (13:46:36), George Kadianakis wrote:
> >> Mike Perry <mikeperry at torproject.org> writes:
> >> > Roger suggested that I enumerate the pros and cons of this increase on
> >> > this mailing list, so we can discuss and consider this switch. So here
> >> > is my attempt at that list. Let's start with a more in-depth recap of
> >> > the one-guard arguments, along with some recent observations that change
> >> > things.
> >> >
> >> > Arguments for staying with just one guard:
> >> >
> >> > 1. One guard means less observability.
> >> >
> >> > As Roger put it in the above blog post: "I think the analysis of the
> >> > network-level adversary in Aaron's paper is the strongest argument for
> >> > restricting the variety of Internet paths that traffic takes between the
> >> > Tor client and the Tor network."
> >> > http://freehaven.net/anonbib/#ccs2013-usersrouted
> >> >
> >> > Unfortunately, we have since learned that Tor's path selection has the
> >> > effect of giving the adversary the ability to generate at least one
> >> > additional observation path. We first became aware of this in
> >> > https://trac.torproject.org/projects/tor/ticket/14917, where the change
> >> > to one guard allowed an adversary to discover your guard by choosing it
> >> > as a rendezvous point and observing the circuit failure. After the fix
> >> > for #14917, the onion service will build a connection to a second guard
> >> > that it keeps in reserve. By using this attack (as well as a similar but
> >> > more involved attack with unique exit policies and carefully chosen /16
> >> > exit node subnets), the adversary can force clients to be observed over
> >> > two paths whenever they like.
> >> >
> >> > So while we may get benefit for moving from three guards to two guards,
> >> > we don't get much (or any) benefit from moving to two guards to one
> >> > guard against an active adversary that either connects to onion
> >> > services, or serves content to clients and runs exits.
> >> >
> >> 
> >> Hmm, that's a fair point. However, the fact that this behavior exists
> >> currently does not mean that it's the best we can do with what we have.
> >> 
> >> Example of what we can do to stop this bad behavior: instead of using
> >> our second guard when our "exit" conflicts with our first guard like
> >> this: [G2 -> M1 -> G1], we could instead make a 4-hop circuit as
> >> follows: [G1 -> M1 -> M2 -> G2]. This would stop us from using our
> >> second guard and would hide the obvious signal you are worrying about.
> >> (I see that dgoulet also suggested that in the ticket comment:7)
> >
> > For hidden service, I think you meant [G1 -> M1 -> M2 -> *G1*] considering
> > that G1 is the chosen RP. But also, I think my comment was very wrong 3 years
> > ago, a service already builds a 4 hops to the RP so it should then be this in
> > your example?: [G1 -> M1 -> M2 -> M3 -> G1]
> 
> Yep, you are right in everything here.
> 
> > This makes it VERY easy for a Guard node to learn that it is the guard of a
> > specific .onion but considering an evil guard of a .onion, there are other
> > effective methods to learn it so I'm not convinced that this path will be
> > worst, just maybe bad for performance.
> 
> Why bad for performance? It will be the same length as currently.
> 
> > But also this would violate tor protocol of "never having the same hop in the
> > path" so overall making an exeception for this makes me worry a bit :S.
> 
> I think this is your main objection to this approach, and I understand
> it, but I'm not sure how well-enforced this tor protocol "rule" is, or
> how much we should respect it given that this is an important security
> edge-case that we can solve.
> 
> > I do agree with Mike on this one that we don't get benefit here from 1 to 2
> > because the code right now is basically a two guard system where the second
> > guard is used rarely. Not only that but an attacker can force you to use that
> > second Guard at will.
> 
> I don't think this is true anymore, if we accept
> [G1 -> M1 -> M2 -> M3 -> G1] as a reasonable solution.

Even if we allow this case, we still run up against other path
restrictions that enable the adversary to force the same new connection
behavior though. If we allow the same guard in multiple points in the
same circuit, new connections can be forced for the case where the RP is
in the same /16 or same family as the guard. This is not the same level
of info, but I still believe that the ability to force a new entry
connection is an extremely bad property. We can only avoid that by
abandoning all circuit restrictions for the RP/exit, or by having two
guards.

I feel vaguely uncomfortable abandoning all of Tor's path restrictions
for certain circuits, but I don't have a good argument against doing
that.

However, given the other benefits from having two dedicated guards
(especially traffic analysis and DoS resistance from conflux, but also
performance), I do believe that always using two guards is clearly and
strictly better than only using two guards for special cases that can be
adversarially controlled.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20180322/48c6a42a/attachment-0001.sig>