[tor-bugs] #7066 [Tor]: Guard disablement by path-bias detector must be disabled or removed

[Tor Bug Tracker & Wiki]

#7066: Guard disablement by path-bias detector must be disabled or removed
------------------------+---------------------------------------------------
 Reporter:  rransom     |          Owner:                    
     Type:  defect      |         Status:  needs_revision    
 Priority:  blocker     |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor         |        Version:                    
 Keywords:  tor-client  |         Parent:                    
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by arma):

 nickm asked me to opine on this one even though i haven't read all the
 components yet. here are my early thoughts:

 - we definitely should not drop guards that go below whatever threshold,
 in 0.2.3.

 - i see these warnings in 0.2.4 in practice when my network gets flaky. i
 assume that means we missed spots in the code where the code concludes
 that the circuit failed and it's the guard's fault, but actually the
 circuit failed and it's the network's fault. i believe these are likely
 bugs in the cbt stuff too. we should at some point aim to refactor all the
 code that cbt touches so we get our behavior wrong in fewer places.

 - since i see these warns in 0.2.4, and therefore assuming that we are
 counting wrong, i am nervous about putting the logs into 0.2.3. i won't
 object to doing so if others really want to, but we should expect an
 ongoing pile of "bug" reports culminating in a good chance that we'll
 decide to take them out later as a backport.

 - if we aren't going to fix the counting bugs in 0.2.3 (i don't think we
 are anytime soon), i wonder if, when we *do* turn things on in 0.2.4 to
 experiment with them, we will end up wishing we didn't trigger false
 warnings in 0.2.3. does that mean we'll want different param names or
 something?

 - i'm really scared of the "dos the network and get people to dump their
 guards" attack. based on tariq's work i'm already planning to argue that
 we should bump up the guard rotation period to 6 months or more. anything
 that reduces that period, especially in a way that's adversary-
 influenceable, produces a very real attack on anonymity, from a very
 realistic adversary. that said, the adversary mike describes is a very
 realistic one too. i should read the proposal in more detail before
 deciding which one i'm more scared by.

 - i don't yet have an opinion on rransom's worry about "three authorities
 can set it to screw you". on first glance it looks like we don't have any
 other consensus params for which three auths can get together to harm
 anonymity. so we may in fact want to set tighter bounds on what failure
 percentages should cause a guard drop -- but i can't really speculate
 about that until we've resolved more of the issues i raise here. i
 wouldn't be opposed to some scheme where 3 auths acting by themselves are
 insufficient to set a consensus param; that should be a separate ticket if
 we want it.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7066#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online