Mike Perry mikeperry@torproject.org writes:
Mike Perry:
teor:
On 25 Apr 2018, at 18:30, Mike Perry mikeperry@torproject.org wrote:
- Hidden service use can't push you over to an unused guard (at all).
- Hidden service use can't influence your choice of guard (at all).
- Exits and websites can't push you over to an unused guard (at all)
- DoS/Guard node downtime signals are rare (absent)
- Nodes are not reused for Guard and Exit positions ("any" positions)
- Information about the guard(s) does not leak to the website/RP (at all).
- Relays in the same family can't be forced to correlate Exit traffic.
I think this list is missing some important user-visible properties, or it's not clear which property above corresponds to these properties:
- Is Tor reliable and responsive when guards go down, or when I move networks, or when I have lost and regained service?
I think this is implicitly provided by #4. Downtime is a security issue. If (any of) a client Guard(s) are down, and the adversary can detect this based on client behavior, well, that is a side channel signal that provides information about the Guard. So by satisfying #4, we also satisfy the weaker conditions of general reliability and responsiveness.
I also think it's missing an implicit property, which we should make explicit:
- Can Tor users be fingerprinted by their set of guards or directory guards?
Perhaps this property is out of scope.
I think it is worth considering. We should add it if we need to do another round of evaluation.
Alright, for the sake of argument, let's call this Property #8: 8. Less information from guard fingerprinting (the least information)
I argue that this #8 is also equivalent to a #9 that Roger would ask for: 9. Fewer points of observation into the network (the fewest points).
If we are actually aiming for 8 and 9 we need to do something about the numdirguard=3 situation, otherwise we still have a huge guard fpr and we still expose ourselves to more of the network even if we keep one guard.
To avoid TL;DR, that argument is an exercise to the reader ;).
Here is a proposal that beats my previous proposal on Property #8 and #9, while trying to preserve as many of the other properties as possible:
- Set "num primary guards"=1 and "num primary guards to use"=1
- Set "num directory guards"=1 and "num directory guards to use"=1
- Don't give Exit nodes the Guard flag.
- Allow "same node, same /16, same family" between guard and last hop, but only for HS circuits (which are at least 4 hops).
- Allow same /16 and same family for HS circuits.
This's for all hops? So all service-side HS circ hops can share the same family? I gues that's OK since we don't know what's happening on the other side of the HS circuit anyhow? Or what?
- When a primary guard leaves the consensus, pick a new one.
- When a primary guard fails circuits, do $MAGIC_FAILURE_HEURISTIC.
What is the $MAGIC_FAILURE_HEURISTIC supposed to do? Also I doubt we can do anything magic here, we even have trouble doing very naive stuff when it comes to network-uptime response.
This proposal gets strong:
- Hidden service use can't push you over to an unused guard (at all).
- Hidden service use can't influence your choice of guard (at all).
- Exits and websites can't push you over to an unused guard (at all)
- Less information from guard fingerprinting (the least information)
It loses #4 (and your reliability point above), because if we transition to a second guard too quickly when the first one starts failing, then we lose the winning fingerprinting property we want to keep. So then therefore, we must tolerate failure and RESOURCELIMIT issues and suffer through connectivity issues during DoS: 4. DoS/Guard node downtime signals are rare (absent)
It then gets us regular: 5. Nodes are not reused for Guard and Exit positions ("any" positions) 6. Information about the guard(s) does not leak to the website/RP (at all). 7. Relays in the same family can't be forced to correlate Exit traffic.
And again, we could get strong #6 if we allow the guard node for both RP and the node before the RP: 6. Information about the guard(s) does not leak to the website/RP (at all).
So the key thing (in this property list) that forcing one guard causes us to lose is reliability under DoS, which is a guard discovery vector (and probably a source of other side channels, too).