[tbb-dev] Documenting best practices for P2P Sybil avoidance over Tor

[Jeremy Rand]

I expect there are benefits to using multiple circuits for onions if 
those circuits are used to isolate different identities.  But yes, 
you're correct (I think) that preventing Sybil attacks is not one of 
those benefits.

Suggesting the following clarified language:

"If your application needs to open a small number of connections (e.g. 
10 long-lived connections) to a P2P network, and you want to prevent 
Sybil attacks, you should seriously consider using a unique SOCKS5 
username per non-onion connection (e.g. by including a new randomly 
generated string in the username each time a connection is opened), 
which will minimize the chance of a malicious exit relay interfering 
with your view of the P2P network.  For example, Bitcoin Core does this. 
  On the other hand, if your application intends to open a very large 
number of connections, you should probably not do this, as it will put 
too much load on the Tor network.  For example, Bitcoin DNS seeders 
should not do this while spidering P2P nodes."

We should also consider giving some advice on what to do when a large 
number of connections are expected (Isis documented the best practices 
for this on the Bitcoin Core issue tracker some years ago), but I don't 
think we should block the above addition on this.  Incrementalism is 
good.  :)

Cheers,
-Jeremy

Richard Pospesel:
> This *seems* reasonable to me.
> 
> tor daemon devs: we should probably explicitly call out best-practices 
> w/ regards to circuit isolation when connecting to onion services as 
> well. I assume there's no point security/privacy-wise in using multiple 
> circuits when connecting to onion services (apart from enabling multiple 
> concurrent streams/channels)?
> 
> 
> On 12/1/21 07:22, Jeremy Rand wrote:
>> Hi Applications Team!
>>
>> I would like to propose the following addendum to the SOCKS username 
>> section of the Tor-Friendly Applications Best Practices:
>>
>> "If your application needs to open a small number of connections (e.g. 
>> 10 long-lived connections) to a P2P network, and you want to prevent 
>> Sybil attacks, you should seriously consider using a unique SOCKS5 
>> username per connection (e.g. by including a new randomly generated 
>> string in the username each time a connection is opened), which will 
>> minimize the chance of a malicious exit relay interfering with your 
>> view of the P2P network.  For example, Bitcoin Core does this.  On the 
>> other hand, if your application intends to open a very large number of 
>> connections, you should probably not do this, as it will put too much 
>> load on the Tor network.  For example, Bitcoin DNS seeders should not 
>> do this while spidering P2P nodes."
>>
>> I think this is probably uncontroversial advice within the Tor 
>> community (I think the Tor devs are aware of Bitcoin Core's behavior 
>> and haven't asked the Bitcoin Core team to change it), but it is not 
>> necessarily obvious to application developers who may be unfamiliar 
>> with Tor, so I think it's worth documenting.  Please let me know if 
>> this text is okay to add (or if there's anything that can be 
>> improved); I don't want to step on toes by adding this without 
>> consulting anyone.
>>
>> Cheers,
>>
>> _______________________________________________
>> tbb-dev mailing list
>> tbb-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
> 
> _______________________________________________
> tbb-dev mailing list
> tbb-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev


-- 
-Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmobile at airmail.cc
Mobile OpenPGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with OpenPGP.
Please don't send me unencrypted messages.
My business email jeremy at veclabs.net is having technical issues at the 
moment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tbb-dev/attachments/20220228/23e67a45/attachment.sig>