On 6 Apr 2016, at 23:42, Ola Bini ola@olabini.se wrote:
Yeah, we talked about that yesterday. Our suggestion is to do something like this:
- if the filtered/reduced sample-set contains less than X (5?) guards,
expand SAMPLED guards using the regular process.
- If SAMPLE guards reach SAMPLED_MAX (50?) size, we fail closed with
an error saying something like "your current network settings make it impossible for us to safely choose an entry guard. If you really need to connect under these circumstances, consider explicitly setting the EntryGuards configuration option"
I suggest we offer "reinstall Tor Browser" or "delete you state file" as a recommended action, because users are more likely to be able to successfully complete those actions, than correctly set "UseEntryGuards".
Oh, wow, I don't think failing closed is a good idea. It means users that move around a lot (and clients which have a longer state history) could fail at some arbitrary time. Why not simply continue to add guards that satisfy the restrictions?
Well, users that move around a lot will only have an expanded sampled set if they move between several different networks that have severe restrictions - but mutually exclusive such restrictions. And we would only ever hit this fail closed if we can't find anything in the sampled set that matches the current needed restrictions. If we keep adding guards, the idea of the sampled set as a measure to minimize exposure to too many guards fly out the window.
The problem really comes down to this - if you have a network that is actively firewalling every guard that is not under their control, if we keep expanding we will sooner or later be forced to use a guard under adversary control. By failing closed, we can avoid that eventuality. However, it seems you don't like that idea - there seems to be some dissent among the Tor devs which approach is best for this situation.
We have to balance the risk of users being funnelled towards a malicious guard, with the risk of denying users access to non-malicious guards.
I think that the more complex the scheme, the more likely it is to have non-obvious failure modes. I'm particularly concerned about failure modes where a user switches between several locations with mutually exclusive firewalling. How many locations would be needed to cause this issue? 50/3 = 16? That's probably ok.
What about guard churn in the consensus? Does that reduce the number of possible locations over time? Because that's a property I think we should avoid. I'm concerned about these kinds of failure modes that only occur in state files that are months or years old. These are very hard to find in testing, and hard to discover during modelling.
Using a malicious guard has similar consequences to Tor failing closed, and users switching to a non-tor browser. I'm not sure which is worse. It probably depends on the user. But we should try to avoid both scenarios.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B