Mike Perry <mikepe...@torproject.org> writes: > In-line below for ease of comment. Also available at: > https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-two-guard-nodes.txt?h=twoguards > > =========================== > > Filename: xxx-two-guard-nodes.txt > Title: The move to two guard nodes > Author: Mike Perry > Created: 2018-03-22 > Supersedes: Proposal 236 > > <snip> > > 3.1. Eliminate path restrictions entirely > > If Tor decided to stop enforcing /16, node family, and also allowed the > guard node to be chosen twice in the path, then under normal conditions, > it should retain the use of its primary guard. > > This approach is not as extreme as it seems on face. In fact, it is hard > to come up with arguments against removing these restrictions. Tor's > /16 restriction is of questionable utility against monitoring, and it can > be argued that since only good actors use node family, it gives influence > over path selection to bad actors in ways that are worse than the benefit > it provides to paths through good actors[10,11]. > > However, while removing path restrictions will solve the immediate > problem, it will not address other instances where Tor temporarily opts > use a second guard due to congestion, OOM, or failure of its primary > guard, and we're still running into bugs where this can be adversarially > controlled or just happen randomly[5]. >
Seems like the above paragraph is our main argument against removing path restrictions. Might be worth pointing out that if congestion/OOM attacks are in our threat model against the current single guard design, then the same adversary can force prop#291 to open a connection to the *third* guard by first doing an OOM/congestion attack against one of your first two guards, and then pushing you to your third guard using a path restriction attack (#14917). Thought that I should mention that because it might be an argument for both moving to two guards and also lifting some path restrictions... _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
