>> The idea would be that Guard_3 would rotate on the order of hours, >> Guard_2 would come from a set that is rotated on the order of days >> (based on the expected duration for the adversary to become Guard_3), and >> Guard_1 would rotate on the order of months (based on the expected >> duration for the adversary to become Guard_2). > > Why set guard 2 to expire in days? If that is less than surveillance speed, > then once the adversary had guard 3, it’s game over.
Sorry, I should have stated this more clearly as "If that is greater than the time needed for surveillance”. And I can imagine rotating guard 2 faster than guard 1 for performance reasons (faster rotation more quickly takes advantage of new capacity in the network). But the only reason that I can see treating guard 2 differently than guard 1 is that you judge the “cost" of the attack starting from guard 2 to be higher, thus compensating for the increase in attack speed. That is, if guard 2 rotates to a malicious relay, the adversary still has to identify and then do a targeted compromised of guard 1, while if a malicious relay is selected as guard 1, then the target HS can be relatively easily observed directly. Such an argument is hard to evaluate carefully, because the costs in terms of added technical and legal complexity are hard to estimate. For example, at what point is it “cheaper" to run more malicious nodes and/or wait longer in hopes of obtaining guard 1 than to try and identify guard 2 but then have to perform surveillance on an identified guard 1? So I would argue to protect guard 2 as much as guard 1, and then look for other, better understood, methods to improve performance. Some fun methods that come to mind are (i) carefully choosing number of primary and secondary guards and (ii) trying to reduce the HS path length, and (iii) allowing HSes to pay for improved performance (yes, I haven’t given up on this idea, haha). Exposing to the HS operator the options controlling the security/performance tradeoff may also be a good option. Cheers, Aaron _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
