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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 twim):

 Replying to [comment:1 yawning]:

 >  * Clients need to know this information when doing path selection, thus
 this information needs to be part of the descriptor/microdescriptor.  Most
 clients only fetch the latter, and those don't even have the full exit
 policy.  How will this impact bootstrapping overhead, particularly when
 relays start to do things like "block all the relays in the US because the
 NSA is spying on them from their orbital satellite platforms" leading to
 gigantic descriptors.

 True, as the network grows and quantum computers are on the way,
 descriptors are going to be huge. I don't think there is a way around it.

 >  * 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@).


 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.


 [1] https://lists.torproject.org/pipermail/tor-dev/2016-May/010977.html

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/19625#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs