[tor-commits] [torspec/master] Clean up verbage.

[nickm at torproject.org]

commit ddf945fd9136f062ab82c4fc76eb013e05da0b52
Author: Mike Perry <mikeperry-git at fscked.org>
Date:   Thu Oct 11 01:59:59 2012 -0700

    Clean up verbage.
---
 proposals/xxx-path-bias-tuning.txt |   61 ++++++++++++++++++-----------------
 1 files changed, 31 insertions(+), 30 deletions(-)

diff --git a/proposals/xxx-path-bias-tuning.txt b/proposals/xxx-path-bias-tuning.txt
index cd4a459..964aedb 100644
--- a/proposals/xxx-path-bias-tuning.txt
+++ b/proposals/xxx-path-bias-tuning.txt
@@ -15,11 +15,10 @@ Overview
 
 Motivation
 
- The Path Bias defense is designed to defend against a type of route
- capture where malicious Guard nodes deliberately fail circuits that
- are determined to extend to non-colluding Exit nodes to maximize
- their network utilization in favor of carrying only compromised
- traffic.
+ The Path Bias defense is designed to defend against a type of route capture
+ where malicious Guard nodes deliberately fail circuits that extend to
+ non-colluding Exit nodes to maximize their network utilization in favor of
+ carrying only compromised traffic.
 
  This attack was explored in the academic literature in [1], and a
  variant involving cryptographic tagging was posted to tor-dev[2] in
@@ -55,7 +54,7 @@ Design Description
  does not produce integer truncation.
 
  No log messages should be displayed, nor should any Guard be
- dropped until it has completed more than 150 first hops.
+ dropped until it has completed at least 150 first hops (inclusive).
 
 Analysis: Simulation
 
@@ -105,7 +104,7 @@ Future Analysis: Deployed Clients
 
  It's my belief that further analysis should be done by deploying 
  loglines for all three thresholds in clients in the live network
- and utilize user reports on how often high rates of circuit failure
+ to utilize user reports on how often high rates of circuit failure
  are seen before we deploy changes to rotate away from failing Guards.
 
  I believe these log lines should be deployed in 0.2.3.x clients,
@@ -131,38 +130,40 @@ Security Considerations
  from a Guard node that previously succeeded 80% of its circuits, an
  adversary would need to induce a 25% success rate for around 350 circuit
  attempts before the client would reject it or a 5% success rate
- for around 215 attempts, using a scaling window of 300 circuits.
-
- Assuming one circuit per Guard per 10 minutes of normal client
+ for around 215 attempts, both using a scaling window of 300 circuits.
+ 
+ Assuming one circuit per Guard per 10 minutes of active client
  activity, this is a sustained network-wide DoS attack of 60 hours
  for the 25% case, or 38 hours for the 5% case.
 
- Presumably this is enough time for the directory authorites to respond
- by altering the pb_disablepct consensus parameter before clients
- rotate.
+ Presumably this is enough time for the directory authorities to respond by
+ altering the pb_disablepct consensus parameter before clients rotate,
+ especially given that most clients are not active for even 38 hours on end,
+ and will tend to stop building circuits while idle.
+
+ If we raised the scaling window to 500 circuits, it would require 1050
+ circuits if the DoS brought circuit success down to 25% (175 hours), and
+ 415 circuits if the DoS brought the circuit success down to 5% (69 hours).
 
- The converse of this, though, is that larger values allow Guard nodes
- to compromise clients for duty cycles of around the size of this window
- (up to the (c/n)^2 * 100/CUTOFF_PERCENT limit in aggregate), so we do
- have to consider that trade off.
+ The tradeoff, though, is that larger scaling window values allow Guard nodes
+ to compromise clients for duty cycles of around the size of this window (up to
+ the (c/n)^2 * 100/CUTOFF_PERCENT limit in aggregate), so we do have to find
+ balance between these concerns.
 
 Implementation Notes: Log Messages
 
  Log messages need to be chosen with care to avoid alarming users.
  I suggest:
 
- Notice: "It appears that your Guard %s is failing a larger number of
- circuits than usual. This could mean that the Guard is overloaded, or
- the Tor network is overloaded. Success counts are %d/%d."
+ Notice: "Your Guard %s is failing more circuits than usual. Most likely
+ this means the Tor network is overloaded. Success counts are %d/%d."
 
- Warn: "It appears that your Guard %s is failing a very large number of
- circuits. Most likely, this could mean that the Guard is overloaded,
- or the Tor network is overloaded, but it could also mean an attack
- against you or the Guard. Success counts are %d/%d."
+ Warn: "Your Guard %s is failing a very large amount of circuits. Most likely
+ this means the Tor network is overloaded, but it could also mean an attack
+ against you or potentially the Guard itself. Success counts are %d/%d."
 
- Drop: "It appears that your Guard %s is failing an extremely large
- number of circuits. [Tor has disabled use of this Guard.] Success
- counts are %d/%d."
+ Drop: "Your Guard %s is failing an extremely large amount of circuits. [Tor
+ has disabled use of this Guard.] Success counts are %d/%d."
 
  The second piece of the Drop message would not be present in 0.2.3.x,
  since the Guard won't actually be dropped.
@@ -177,13 +178,13 @@ Implementation Notes: Consensus Parameters
    The minimum number of first hops before we log or drop Guards.
 
  pb_noticepct=70
-   The threshhold of circuit success below which we display a notice.
+   The threshold of circuit success below which we display a notice.
 
  pb_warnpct=50
-   The threshhold of circuit success below which we display a warn.
+   The threshold of circuit success below which we display a warn.
 
  pb_disablepct=30
-   The threshhold of circuit success below which we disable the guard.
+   The threshold of circuit success below which we disable the guard.
 
  pb_scalecircs=300
    The number of first hops at which we scale the counts down.