#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