[or-cvs] r12667: a few more thoughts on mirroring dist/ on bridges (tor/trunk/doc/spec/proposals)

[arma@xxxxxxxx]

Author: arma
Date: 2007-12-04 13:34:30 -0500 (Tue, 04 Dec 2007)
New Revision: 12667

Modified:
   tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt
Log:
a few more thoughts on mirroring dist/ on bridges


Modified: tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt
===================================================================
--- tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt	2007-12-04 16:29:26 UTC (rev 12666)
+++ tor/trunk/doc/spec/proposals/127-dirport-mirrors-downloads.txt	2007-12-04 18:34:30 UTC (rev 12667)
@@ -1,5 +1,5 @@
 Filename: 127-dirport-mirrors-downloads.txt
-Title: Relaying dirport requests to Tor download site
+Title: Relaying dirport requests to Tor download site / website
 Version: $Revision$
 Last-Modified: $Date$
 Author: Roger Dingledine
@@ -14,7 +14,7 @@
   We have a big pile of mirrors (google for "Tor mirrors"), but few of
   our users think to try a search like that. Also, many of these mirrors
   might be automatically blocked since their pages contain words that
-  might cause them to get blocked. And lastly, we can imagine a future
+  might cause them to get banned. And lastly, we can imagine a future
   where the blockers are aware of the mirror list too.
 
   Here we describe a new set of URLs for Tor's DirPort that will relay
@@ -36,32 +36,33 @@
   Check out the connection_ap_make_link() function, as called from
   directory.c. Tor clients use this to create a "fake" socks connection
   back to themselves, and then they attach a directory request to it,
-  so they can launch directory fetches via Tor. We could piggyback on
+  so they can launch directory fetches via Tor. We can piggyback on
   this feature.
 
-3. One-hop circuits or three-hop circuits?
+3. Direct connections, one-hop circuits, or three-hop circuits?
 
   We could relay the connections directly to the download site -- but
   this produces recognizable outgoing traffic on the bridge or cache's
   network, which will probably surprise our nice volunteers. (Is this
   a good enough reason to discard the direct connection idea?)
 
-  But we still have a choice: should we do a one-hop begindir-style
-  connection to the mirror site (make a one-hop circuit to it, then send a
-  'begindir' cell down the circuit), or should we do a normal three-hop
-  anonymized connection?
+  Even if we don't do direct connections, should we do a one-hop
+  begindir-style connection to the mirror site (make a one-hop circuit
+  to it, then send a 'begindir' cell down the circuit), or should we do
+  a normal three-hop anonymized connection?
 
-  If these mirrors are mainly bridges, doing a one-hop connection creates
-  another way to enumerate bridges. That would argue for three-hop. On
-  the other hand, downloading a 10+ megabyte installer through a normal
-  Tor circuit can't be fun. But if you're already getting throttled a
-  lot because you're in the "relayed traffic" bucket, you're going to
-  have to accept a slow transfer anyway. So three-hop it is.
+  If these mirrors are mainly bridges, doing either a direct or a one-hop
+  connection creates another way to enumerate bridges. That would argue
+  for three-hop. On the other hand, downloading a 10+ megabyte installer
+  through a normal Tor circuit can't be fun. But if you're already getting
+  throttled a lot because you're in the "relayed traffic" bucket, you're
+  going to have to accept a slow transfer anyway. So three-hop it is.
 
   Speaking of which, we would want to label this connection
   as "relay" traffic for the purposes of rate limiting; see
   connection_counts_as_relayed_traffic() and or_conn->client_used. This
-  will be a bit tricky though, because it uses the bridge's guards.
+  will be a bit tricky though, because these connections will use the
+  bridge's guards.
 
 4. Scanning resistance
 
@@ -69,10 +70,11 @@
   it hard to scan large swaths of the Internet to look for responses
   that indicate a bridge.
 
-  In general this is a really hard problem, so it's not critical that
-  we solve it here. But we can note that some bridges should open their
-  DirPort (and offer this functionality), and others shouldn't. Then some
-  bridges provide a download mirror while others are scanning-resistant.
+  In general this is a really hard problem, so we shouldn't demand to
+  solve it here. But we can note that some bridges should open their
+  DirPort (and offer this functionality), and others shouldn't. Then
+  some bridges provide a download mirror while others can remain
+  scanning-resistant.
 
 5. Integrity checking
 
@@ -87,7 +89,7 @@
 
   Answer #1: Users need to do pgp signature checking. Not a very good
   answer, a) because it's complex, and b) because they don't know the
-  right signatures in the first place.
+  right signing keys in the first place.
 
   Answer #2: The mirrors could exit from a specific Tor relay, using the
   '.exit' notation. This would make connections a bit more brittle, but
@@ -103,9 +105,12 @@
   network signature -- either by looking for known bytes in the binary,
   or by looking for "GET /tor/dist/"? It would be nice to encrypt the
   connection from the bridge user to the bridge. And we can! The bridge
-  already supports TLS.  Rather than initiating a TLS renegotiation after
+  already supports TLS. Rather than initiating a TLS renegotiation after
   connecting to the ORPort, the user should actually request a URL. Then
   the ORPort can either pass the connection off as a linked conn to the
   dirport, or renegotiate and become a Tor connection, depending on how
   the client behaves.
 
+  I suggest we go with Answers 2 and 3 for now, and keep 4 in mind for
+  down the road.
+