Mike Perry mikeperry@torproject.org writes:
In-line below for ease of comment. Also available at: https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-...
===========================
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...