[tor-commits] [torspec/master] add in a point that rransom and i independently came up with

[arma at torproject.org]

commit 37c8237aafdb416507be0eeb8638ec0c9f01e5a4
Author: Roger Dingledine <arma at torproject.org>
Date:   Tue Jun 12 06:32:01 2012 -0400

    add in a point that rransom and i independently came up with
---
 proposals/188-bridge-guards.txt |    8 +++++++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/proposals/188-bridge-guards.txt b/proposals/188-bridge-guards.txt
index 3c53cfb..5a5a005 100644
--- a/proposals/188-bridge-guards.txt
+++ b/proposals/188-bridge-guards.txt
@@ -32,7 +32,7 @@ Status: Open
    same way clients do.  This has been a known attack since early
    versions {XXXX check} of the design document; let's try to fix it.
 
-2.1. Related ideas: Guard nodes
+2.1. Related idea: Guard nodes
 
    The idea of guard nodes isn't new: since 0.1.1, Tor has used guard
    nodes (first designed as "Helper" nodes by Wright et al in {XXXX})
@@ -203,6 +203,12 @@ Status: Open
    from learning that we're a bridge... but another set of nodes will
    learn that anyway, so it's not clear what we'd gain.
 
+   One good reason to keep separate guard lists is to prevent the
+   *client* of the bridge from being able to enumerate the guards that
+   the bridge uses to protect its own traffic (by extending a circuit
+   through the bridge to a node it controls, and finding out where the
+   extend request arrives from).
+
 5. Other considerations
 
    What fraction of our traffic is bridge traffic?  Will this alter