> On 6 Apr 2016, at 23:42, Ola Bini <ola@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev