From: Roger Dingledine <arma@torproject.org>
Date: Sun, 2 Dec 2007 13:51:16 +0000 (+0000)
Subject: another attack on bridges. darn it.
X-Git-Tag: tor-0.2.0.13-alpha~105
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=25a43314d1e4133b8d0a9de833802929e606ab7f;p=thirdparty%2Ftor.git

another attack on bridges. darn it.


svn:r12639
---

diff --git a/doc/spec/proposals/125-bridges.txt b/doc/spec/proposals/125-bridges.txt
index 3b96ecd9d5..1a3f6c5685 100644
--- a/doc/spec/proposals/125-bridges.txt
+++ b/doc/spec/proposals/125-bridges.txt
@@ -329,3 +329,20 @@ Status: Open
   Once proposal 124 (modified TLS handshake) is in place, we should
   consider doing the switch. This might even be in the 0.2.0.x timeframe.
 
+3.8. Do we need a second layer of entry guards?
+
+  If the bridge user uses the bridge as its entry guard, then the
+  triangulation attacks from Lasse and Paul's Oakland paper work to
+  locate the user's bridge(s).
+
+  Worse, this is another way to enumerate bridges: if the bridge users
+  keep rotating through second hops, then if you run a few fast servers
+  (and avoid getting considered an Exit or a Guard) you'll quickly get
+  a list of the bridges in active use.
+
+  That's probably the strongest reason why bridge users will need to
+  pick second-layer guards. Would this mean bridge users should switch
+  to four-hop circuits?
+
+  We should figure this out in the 0.2.1.x timeframe.
+