[tor-bugs] #19625 [Core Tor/Tor]: Allow relays to set peering policy

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Jul 8 18:38:57 UTC 2016


#19625: Allow relays to set peering policy
----------------------------+-----------------------------------
 Reporter:  twim            |          Owner:
     Type:  project         |         Status:  needs_information
 Priority:  Medium          |      Milestone:
Component:  Core Tor/Tor    |        Version:
 Severity:  Normal          |     Resolution:
 Keywords:  needs-proposal  |  Actual Points:
Parent ID:                  |         Points:
 Reviewer:                  |        Sponsor:
----------------------------+-----------------------------------

Comment (by yawning):

 Replying to [comment:3 twim]:
 > Replying to [comment:1 yawning]:
 > >  * How would one guard against malicious relays using this mechanism
 to mount a partitioning attack.  More generically, currently clients are
 responsible for 100% of the path selection.  What is the
 security/anonymity impact of allowing potentially malicious relays to
 influence this.
 >
 > These relays can influence this right now and not be caught (we
 discussed this at tor-relays@).

 Well, that's why someone needs to write a clique reachability test.  The
 path selection code is written under the assumption that the Tor Network
 in it's ideal form is a complete graph.  Giving relays the ability to
 break edges on the graph arbitrarily is bad in that it influences client
 path selection (why should the client trust the relay operator's idea of
 "what an acceptable peer to connect to" is).

 Basically, I don't view "relays can currently engage in bad behavior and
 get away with it" as a compelling reason for making it easier to do said
 bad behavior, and I want the clique reachability instrumentation so that
 relays that do engage in bad behavior are easier to detect and reject.

 > There was an idea at tor-dev@ discussion [1], that seems really nice and
 straightforward to me:
 >
 > Rob van der Hoeven:
 > > Maybe a client can download all descriptors, but
 > > only store a fixed number of (randomly selected) routers? This could
 be
 > > a configuration option, something like: maxDescriptorStorageCount.
 >
 > The point is to do path selection *before* we need any paths. A client
 parses the consensus and picks relays in advance for all possible purposes
 since only small fraction of consensus is really used.
 > For a passive adversary it looks like the client just downloads
 consensus, so there is no way to mount partitioning attack (all clients
 have the same consensus).
 > Honestly I don't see any new attack surface with 'early path selection'.
 Maybe you are.

 This will scale like utter shit for certain use cases, and beyond saving
 bandwidth in fetching descriptors, is totally orthogonal to "intermediary
 relays can impose restrictions to clients on what peers they can extend
 the circuit to".

 Anyway.  If you care about this feature, write a proposal.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19625#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list