Re: [tor-bugs] #8240 [Tor]: Raise our guard rotation period

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#8240: Raise our guard rotation period
----------------------------------------------------+-----------------------
 Reporter:  arma                                    |          Owner:                    
     Type:  defect                                  |         Status:  needs_revision    
 Priority:  major                                   |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor                                     |        Version:                    
 Keywords:  tor-client needs-proposal 023-backport  |         Parent:                    
   Points:                                          |   Actualpoints:                    
----------------------------------------------------+-----------------------

Comment(by mikeperry):

 Replying to [comment:34 arma]:
 > Well, here we are in a deadlock again.
 >
 > If we merge the consensus parameter version to 0.2.3 (or heck, to
 0.2.4), but we don't add any rebalancing code to these versions, then when
 it comes time to set that consensus parameter, we're going to hesitate and
 try not to do it, right?

 The consensus parameter version is in main-0.2.4.x. The merge commit was
 6f20a74d52741cce521cf03b8afee570e3cb367b.

 > We need a lot of our users to be choosing based on the new (not yet
 designed, not yet implemented, not yet deployed) weighting strategy, when
 we tell a lot of our users to lengthen their guard rotation interval.
 Unless I'm mistaken?

 > Or is Mike recommending that we roll out the consensus parameter
 version, have many of our users change to 9 months, then figure we'll do
 #8453 and then the newer users will slowly upgrade to that newer code and
 eventually we'll be rebalanced again?

 I don't plan to push back against the consensus parameter increase for
 values like 2 months.

 However, anything more I think is unwise for several reasons: We need load
 balancing fixes; defense-in-depth fixes against path bias and route
 capture attacks that are possible via Guard node key compromise; and
 better protection against the ability of the Guard nodes of hidden
 services to be discovered.

 I also don't fully believe that simply raising the Guard lifespan is the
 best defense against rpw's hidden service paper against all classes of
 adversary. In the event that you can find the service's Guard nodes so
 much more quickly than you could find the client after a few months of
 guard rotation, it seems *worse* to make them stick with those Guard nodes
 even longer.

 For clients, it seems clear to me that you should have your Guard node for
 a function of the amount of time it takes for the adversary to discover
 it. Because of this, I think I *do* want to go back to arguing that the
 minimum accepted torrc value should be an hour for clients (this is the
 duration of rpw's attack).

 I think the risk calculations might be different for hidden services than
 for clients, but near as I can tell, I think a longer Guard duration means
 we just dumped a whole lot of risk onto our Guard nodes, and we're going
 to make it a whole lot worse by making those guard nodes targets for much
 longer periods of time..

 If we can fix all of the attacks that stealing Guard node identity keys
 enables *and* make it harder to discover Guard nodes in the first place,
 then I might be talked into values like 9-12 months.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8240#comment:35>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs