<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div><br></div></div><div>On 28 Aug 2018, at 13:13, Nathaniel Suchy <<a href="mailto:me@lunorian.is">me@lunorian.is</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">This thread continues the broader discussion of Tor Circuit path selection discussed at <a href="https://lists.torproject.org/pipermail/tor-relays/2018-August/015994.html">https://lists.torproject.org/pipermail/tor-relays/2018-August/015994.html</a> regarding possible correlation attacks by an autonomous system.<div><br></div><div><b>Current measures include:</b></div><div>* Preventing two relays from the same /16 in IPv4 and /32 in IPv6 networks, from being in the same Tor circuit. CIDR is helpful, but is it enough?</div><div>* The MyFamily directive, this does rely on relay operators being honest and we shouldn't rely on this as the sole indicator.</div><div>* Others things that I am not aware of?</div></div></div></blockquote><div><br></div><div>That's a good summary, there are a few more details about Guards in:</div><div><a href="https://gitweb.torproject.org/torspec.git/tree/path-spec.txt#n230">https://gitweb.torproject.org/torspec.git/tree/path-spec.txt#n230</a></div><div><br></div><div>Since 0.2.9, all relays in the consensus have the Running and Valid flags,</div><div>so those constraints are redundant:</div><div><a href="https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2295">https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2295</a></div><div><br></div><div>A recent proposal talks about removing path restrictions altogether,</div><div>in favour of vanguards (layered guards):</div><div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/292-mesh-vanguards.txt#n177">https://gitweb.torproject.org/torspec.git/tree/proposals/292-mesh-vanguards.txt#n177</a></div><br><blockquote type="cite"><div><div dir="ltr"><div><b>Some measures worth considering include:</b></div><div>* Preventing two relays in the same ASN from being in a circuit.</div><div>* Maybe prevent two relays in the same ASN from being Guard and Exit, excluding the middle relay from this calculation.</div></div></div></blockquote><div><br></div><div>ASN data needs to be authenticated and distributed to clients, or we introduce</div><div>a security dependency on an external data provider. Search the archives for</div><div>details.</div><br><blockquote type="cite"><div><div dir="ltr"><div>* Bridges could be a challenge when implementing this, although it's not impossible.</div></div></div></blockquote><div><br></div><div>Clients already impose the IPv4 /16 constraint on paths they build via bridges.</div><div>What's the challenge here?</div><br><blockquote type="cite"><div><div dir="ltr"><div>* Looking at relays with same/similar names, heuristics maybe? It's really guesswork but hey it might work.</div><div>* Looking at relays with same/similar contact info</div></div></div></blockquote><div><br></div><div>Changing path selection based on data that hasn't been verified introduces</div><div>additional attack vectors. I think there are previous posts on this topic, but</div><div>I'm not sure.</div><br><blockquote type="cite"><div><div dir="ltr"><div>* Looking at relays in the same geographic regions and avoiding them</div></div></div></blockquote><div><br></div><div>Country data is very poor quality: it's generally a mix of geographical location</div><div>of the actual relay, and legal location of the data centre company. It's also not</div><div>authenticated or validated, introducing a dependency on an external data</div><div>provider.</div><div><br></div><div>We need more research to determine what the threat models are, how country</div><div>data is useful, and what the default settings should be.</div><br><blockquote type="cite"><div><div dir="ltr"><div>* Relays with the same non-standard ports - excluding 9001, 9030, 80, 443 (anything else that's super common?)</div></div></div></blockquote><div><br></div><div>The assumption is that relays with the same ports might have the same operator.</div><div>ORPorts are verified by the directory authorities, so we could use them.</div><div><br></div><div>I think the logic should be:</div><div>If fewer than X% of relays have a port, consider all those relays to be in the same</div><div>family.</div><div><br></div><div>Here are the open questions:</div><div>What should X be? (Look at existing port distribution.)</div><div>Should we use number of relays, or consensus weight?</div><div><br></div><div>The next step is to write a proposal:</div><div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt">https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt</a></div><br><blockquote type="cite"><div><div dir="ltr"><div>* On device models looking at the above data to make decisions of which relays are most likely run by the same entity, use machine learning to make an informed decision based on all factors maybe?</div></div></div></blockquote><div><br></div><div>Machine learning is easily manipulated, hard to update, and hard to distribute.</div><br><blockquote type="cite"><div><div dir="ltr"><div><b>Papers worth reviewing:</b></div><div>* AS-awareness in Tor Path Selection <a href="https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf">https://www.freehaven.net/anonbib/cache/DBLP:conf/ccs/EdmanS09.pdf</a></div><div>* Users Get Routed:
Traffic Correlation on Tor by Realistic Adversaries <a href="https://www.ohmygodel.com/publications/usersrouted-ccs13.pdf">https://www.ohmygodel.com/publications/usersrouted-ccs13.pdf</a></div><div>* Moving Tor Circuits Towards Multiple-Path: Anonymity and
Performance Considerations <a href="https://pdfs.semanticscholar.org/aa94/7dd4762bd0f6531bacfeac9d29ef1e1d4cd6.pdf">https://pdfs.semanticscholar.org/aa94/7dd4762bd0f6531bacfeac9d29ef1e1d4cd6.pdf</a></div><div>* Avoiding The Man on the Wire: Improving Tor’s
Security with Trust-Aware Path Selection <a href="https://www.nrl.navy.mil/itd/chacs/sites/www.nrl.navy.mil.itd.chacs/files/pdfs/16-1231-4380.pdf">https://www.nrl.navy.mil/itd/chacs/sites/www.nrl.navy.mil.itd.chacs/files/pdfs/16-1231-4380.pdf</a></div></div></div></blockquote><div><br></div><div>Recent tor proposals:</div><div><br></div><div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt">https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-selection.txt</a></div><div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/277-detect-id-sharing.txt">https://gitweb.torproject.org/torspec.git/tree/proposals/277-detect-id-sharing.txt</a></div><div><a href="https://gitweb.torproject.org/torspec.git/tree/proposals/291-two-guard-nodes.txt">https://gitweb.torproject.org/torspec.git/tree/proposals/291-two-guard-nodes.txt</a></div><br><blockquote type="cite"><div><div dir="ltr"><div><b>Outside the scope:</b></div><div>* In AS-es where Virtual Machines are sold, and Physical Machines are not. It's quite possible that the provider may steal relay keys. Little research exists where you could successfully protect against such an adversary who isn't playing nice. Legislation (For example, GDPR) in the EU exists where such activity may violate local laws. This may or may not be enough. Certainly not against a government actor, but against an AS doing it per their only devices maybe.</div></div></div></blockquote><div><br></div><div>Physical access to the device also provides the opportunity to access data</div><div>on the device. It is also out of scope.</div><br><blockquote type="cite"><div><div dir="ltr"><div>* An AS hosting a Tor relay who logs or watches network traffic will always be able to learn something about the circuit, but perhaps we can prevent them from learning everything about the circuit most of the time.</div></div></div></blockquote><div><br></div><div>Tor is designed so that that each relay learns some information, but no relay</div><div>learns all the information. That's why we have path constraints for similar relays:</div><div><a href="https://tor.stackexchange.com/questions/27/how-does-tors-threat-model-differ-from-i2ps-threat-model#277">https://tor.stackexchange.com/questions/27/how-does-tors-threat-model-differ-from-i2ps-threat-model#277</a></div><div><br></div><blockquote type="cite"><div><div dir="ltr"><div>Everyone on the list has a had very insightful and helpful thoughts on this discussion so far and I'm looking forward to getting more discussion of the broader issue.</div></div></div></blockquote><br><div>T</div></body></html>