Tim Wilson-Brown - teor teor2345@gmail.com writes:
[ text/plain ]
On 27 Mar 2016, at 05:42, s7r s7r@sky-ip.org wrote:
Hello,
teor, asn, see comments inline.
On 3/24/2016 5:00 PM, Tim Wilson-Brown - teor wrote: [snip] The proposal ignores client bootstrap.
There are a limited number of hard-coded authorities and fallback directories available during client bootstrap. The client doesn't select guards until it has bootstrapped from one of the 9 authorities or 20-200 fallback directories.
I think this step is before prop#259 does its magic, since prop#259 first needs a consensus before it can work. Let's call this initial (genesis) bootstrap Step 0 - only after a client has bootstrapped (either from an authority or from a fallback directory) he will initiate prop#259 to pick a guard.
So do we throw away the information about reachable ports we gained during bootstrap? It's simpler, but slower. Perhaps too slow for a good user experience.
Hmm, seems like there are bits of reachability information all around the bootstrapping process :) I wonder how we could actually use them...
Here are two brainstormy/sucky ideas for heuristics:
a) If during bootstrapping we only connected to 80/443 bridges, then enable the dystopic mode (e.g. only use 80/443 bridges or sth).
A more conservative approach here, is to add points to the heuristic for each 80/443 bridge we connect to, and after enough points have been accumulated we assume that the network is dystopic and enable the dystopic mode.
b) When choosing guards we strictly prefer ports we managed to connect to during bootstrapping.
Both of those approaches are not bulletproof and can lead to false positives (i.e. we go into dystopic mode, even when the network is fine) which kind of suck because of security concerns (increased chances of using a dystopic guard) and for load balancing concerns.
They can also take obviously wrong decisions when a person moves around with their laptop a lot. Heuristic decisions from one network will carry over to the next network if Tor has not restarted.
I think more research is needed to find out how to use this information well.
Other Considerations
We're considering increasing the 10 second stream attach timeout to support users on slow and unreliable network connections (#16844). We should think about the impact of that on this proposal - I'd hate to double the time it takes tor to exhaust its UTOPIC guardlist.
This is correct.
Also, FascistFirewall torrc option: prop#259 sounds like it will take care of users behind FascistFirewalls by default, should we eliminate it entirely for simplicity? Or should we make it that FascistFirewall 1 will tell prop#259 to populate SAMPLED_GUARDS list only with dystopic guards OR use only a SAMPLED_DYSTOPIC_GUARDS list if we choose to keep the two lists disjoint?
It depends how quickly we can auto-discover whether we're firewalled or not. If it's going to take more than 30 seconds (typical user attention span), I'd use FascistFirewall as a hint to populate the UTOPIC lists. This will happen automatically if we only populate the UTOPIC list with reachable addresses. (Tor handles FascistFirewall, ReachableAddresses, and ClientUseIPv4/6 using the same set of functions.)
I wonder what would happen there if FascistFirewall gets toggled on and off.
If our guardlist was sampled when FascistFirewall was on, shouldn't we sample from the beginning if FascistFirewall goes off? That's terrible though since we lose all that guard state...
More thinking is required here as well.