I think the option to rate-limit guard selection is a great idea to defend against guard DoS. The downside is possible connection loss even if you’re not under attack and you just happen to pick flaky guards. In case you’re interested, I examined this defense and how often such benign service loss would occur in section 6.B of "The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network” http://ohmygodel.com/publications/sniper-ndss14.pdf. Table 6 shows the probability that this happens for a Tor client that operates continuously for two months (after 2-3 months all guards will have expired and the process repeats). If, for example, you are willing to require only one active guard (a_g=1) and you limit yourself to no more than 4 new guards (r=4) chosen in the last 28 days (t=28), then you had a 0.0008 chance of having any down time (whether or not it happens depends on which guards you chose). If you increase the number of allowed new guards to 5 (r=5), then the probability of downtime was zero.

Cheers, Aaron

Got it. Though on the client side, could we have a warning or have an option to hibernate a HS if they have been forced to switch guards N times in the last N minutes or hours or such? This would allow a DNS on the HS of course, but that may be preferable to discovery.

David Chasteen

PGP 0x48458ecd78833c0d

On Nov 9, 2014 12:49 PM, "Matthew Finkel" matthew.finkel@gmail.com wrote: On Sun, Nov 09, 2014 at 12:34:01PM -0500, David Chasteen wrote:

...

Would it be possible to create some kind of tor weather-like detection and alert system to warn if such a massive DoS attack were underway such that users could know that perhaps now might not be the best possible time to use Tor? A hidden threat is worse than a known one. We're not going to be able to mitigate every known threat, but making users aware that the threat profile is heightened can allow them to make informed risk decisions.

Unfortunately we don't receive any real-time statistics from relays, and our metrics calculations are run daily, so there's a significant delay in any visualizations we generate. Perhaps we can still look for and see long-term attacks (> 24-36 hours) but nothing that will significantly benefit users shortly after the attack begins. _______________________________________________ tor-internal mailing list tor-internal@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-internal _______________________________________________ tor-internal mailing list tor-internal@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-internal