[or-cvs] tweaks outside sec4 (couldn"t help myself)

[arma@seul.org (Roger Dingledine)]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-design.tex 
Log Message:
tweaks outside sec4 (couldn't help myself)


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- tor-design.tex	26 Oct 2003 22:59:18 -0000	1.28
+++ tor-design.tex	26 Oct 2003 23:49:01 -0000	1.29
@@ -100,7 +100,7 @@
 Tor now uses an incremental or \emph{telescoping}
 path-building design, where the initiator negotiates session keys with
 each successive hop in the circuit.  Once these keys are deleted,
-subsequent compromised nodes cannot decrypt old traffic.
+subsequently compromised nodes cannot decrypt old traffic.
 As a side benefit, onion replay detection is no longer
 necessary, and the process of building circuits is more reliable, since
 the initiator knows when a hop fails and can then try extending to a new node.
@@ -122,7 +122,7 @@
 \item \textbf{Many TCP streams can share one circuit:} The original
 Onion Routing design built a separate circuit for each application-level
 request.
-This hurt perfomance by requiring multiple public key operations for
+This hurt performance by requiring multiple public key operations for
 every request, and also presented
 a threat to anonymity (see Section~\ref{maintaining-anonymity}).
 \footnote{The first Onion Routing design \cite{or-ih96} protected against
@@ -145,20 +145,18 @@
 The current Tor design multiplexes multiple TCP streams along each virtual
 circuit, in order to improve efficiency and anonymity.
 
-\item \textbf{No mixing, padding, or traffic shaping:} 
-The original Onion Routing
-design called for full link padding both between onion routers and between
-onion proxies (that is, users) and onion routers \cite{or-jsac98}. The
+\item \textbf{No mixing, padding, or traffic shaping:} The original
+Onion Routing design called for mixing of data from each circuit,
+plus full link padding both between onion routers and between onion
+proxies (that is, users) and onion routers \cite{or-jsac98}. The
 later analysis paper \cite{or-pet00} suggested \emph{traffic shaping}
 to provide similar protection but use less bandwidth, but did not go
-into detail.  However, recent research \cite{econymics} and deployment
+into detail. However, recent research \cite{econymics} and deployment
 experience \cite{freedom21-security} suggest that this level of resource
 use is not practical or economical; and even full link padding is still
-vulnerable to active attacks \cite{defensive-dropping}.
-%[An upcoming FC04 paper. I'll add a cite when it's out. -RD]
-Thus, absent a proven design for traffic shaping, Tor currently generates 
-no dummy traffic. 
-% We don't mention mixing in the above, but we mention it in the title. -NM
+vulnerable \cite{defensive-dropping}. Thus, until we have a proven and
+convenient design for traffic shaping or low-latency mixing that will help
+anonymity against a realistic adversary, we leave these strategies out.
 
 \item \textbf{Leaky-pipe circuit topology:} Through in-band
   signalling within the
@@ -180,11 +178,10 @@
 at the edges of the network to detect congestion or flooding attacks
 and send less data until the congestion subsides.
 
-\item \textbf{Directory servers:} Rather take the original Onion
-Routing's approach and  attempting to flood
-link-state information through the network --- an approach which can be
-unreliable and
-open to partitioning attacks or outright deception --- Tor takes a simplified
+\item \textbf{Directory servers:} The original Onion Routing design
+planned to flood link-state information through the network --- an
+approach which can be unreliable and
+open to partitioning attacks or outright deception. Tor takes a simplified
 view towards distributing link-state information. Certain more trusted
 onion routers also serve as directory servers; they provide signed
 \emph{directories} describing all routers they know about, and which
@@ -229,19 +226,23 @@
 to exit the Tor network from his node.
 
 \item \textbf{Implementable in user-space:} Because it only attempts to
-anonymize TCP streams, Tor differs from some other anonymity
-systems\cite{freedom} in that it does not require patches to an operating
+anonymize TCP streams, Tor differs from other anonymity systems like
+Freedom \cite{freedom} in that it does not require patches to an operating
 system's network stack in order to operate.  Although this approach is less
-flexible, it has proven valuable to Tor's portability and deployabilitiy.
+flexible, it has proven valuable to Tor's portability and deployability.
 
 \item \textbf{Rendezvous points and location-protected servers:} Tor
-provides an integrated mechanism for responder-anonymity
+provides an integrated mechanism for responder anonymity via
 location-protected servers.  Previous Onion Routing designs included
 long-lived ``reply onions'' which could be used to build virtual
-circuits towards a hidden server, but this design is vulnerable to
-flooding attacks, and is incompatible with forward security.  In Tor's
+circuits to a hidden server, but this approach is 
+brittle because a reply onion becomes useless if any node in the
+path goes down or rotates its keys, and it's also
+%vulnerable to flooding attacks,
+% no it isn't. no more than our rendezvous point approach at least -RD
+incompatible with forward security.  In Tor's
 current design, clients use {\it introduction points} to negotiate {\it
-  rendezvous points} to connect with hidden servers, and reply onions
+rendezvous points} to connect with hidden servers; and reply onions
 are no longer required.
 \end{tightlist}
 
@@ -528,7 +529,7 @@
 %  for later. -PS
 
   
-\item{Hostile Tor node:] can arbitrarily manipulate the
+\item{Hostile Tor node:} can arbitrarily manipulate the
   connections under its control, as well as creating new connections
   (that pass through itself).
 \end{description}
@@ -735,7 +736,7 @@
 \begin{equation}
 \begin{aligned}
 \mathrm{Alice} \rightarrow \mathrm{Bob}&: E_{PK_{Bob}}(g^x) \\
-\mathrm{Bob} \rightarrow \mathrm{Alice}&: g^y, H(K | \mathrm{``handshake''}) \\
+\mathrm{Bob} \rightarrow \mathrm{Alice}&: g^y, H(K | \mathrm{``handshake"}) \\
 \end{aligned}
 \end{equation}
 
@@ -893,7 +894,7 @@
 
 even limiting most nodes to allow http, ssh, and aim to exit and reject
 all other stuff is sketchy, because plenty of abuse can happen over
-port 80. but it's a good start, because it blocks most things,
+port 80. but it's a surprisingly good start, because it blocks most things,
 and because people are more used to the concept of port 80 abuse not
 coming from the machine's owner.
 
@@ -1028,7 +1029,8 @@
 advertise several onion routers (his \emph{Introduction Points}) as his
 public location. Alice, the client, chooses a node for her \emph{Meeting
 Point}. She connects to one of Bob's introduction points, informs him
-about her meeting point, and then waits for him to connect to the meeting
+about her rendezvous point, and then waits for him to connect to the
+rendezvous
 point. This extra level of indirection means Bob's introduction points
 don't open themselves up to abuse by serving files directly, eg if Bob
 chooses a node in France to serve material distateful to the French. The
@@ -1048,15 +1050,15 @@
 \item Alice learns about Bob's service out of band (perhaps Bob told her,
       or she found it on a website). She looks up the details of Bob's
       service from the DHT.
-\item Alice chooses and establishes a Meeting Point (MP) for this
+\item Alice chooses and establishes a Rendezvous Point (RP) for this
       transaction.
 \item Alice goes to one of Bob's Introduction Points, and gives it a blob
-      (encrypted for Bob) which tells him about herself, the Meeting Point
+      (encrypted for Bob) which tells him about herself, the RP
       she chose, and the first half of an ephemeral key handshake. The
       Introduction Point sends the blob to Bob.
-\item Bob chooses whether to ignore the blob, or to onion route to MP.
+\item Bob chooses whether to ignore the blob, or to onion route to RP.
       Let's assume the latter.
-\item MP plugs together Alice and Bob. Note that MP can't recognize Alice,
+\item RP plugs together Alice and Bob. Note that RP can't recognize Alice,
       Bob, or the data they transmit (they share a session key).
 \item Alice sends a Begin cell along the circuit. It arrives at Bob's
       onion proxy. Bob's onion proxy connects to Bob's webserver.
@@ -1073,11 +1075,11 @@
 The blob that Alice gives the introduction point includes a hash of Bob's
 public key to identify the service, an optional initial authentication
 token (the introduction point can do prescreening, eg to block replays),
-and (encrypted to Bob's public key) the location of the meeting point,
-a meeting cookie Bob should tell the meeting point so he gets connected to
+and (encrypted to Bob's public key) the location of the rendezvous point,
+a rendezvous cookie Bob should tell RP so he gets connected to
 Alice, an optional authentication token so Bob can choose whether to respond,
-and the first half of a DH key exchange. When Bob connects to the meeting
-place and gets connected to Alice's pipe, his first cell contains the
+and the first half of a DH key exchange. When Bob connects to RP
+and gets connected to Alice's pipe, his first cell contains the
 other half of the DH key exchange.
 
 % briefly talk about our notion of giving cookies to people proportional
@@ -1095,7 +1097,7 @@
 lookup system on the directory servers.)  Bob publishes into the DHT
 (indexed by the hash of the public key) the public key, an expiration
 time (``not valid after''), and the current introduction points for that
-service. Note that Bob's webserver is completely oblivious to the fact
+service. Note that Bob's webserver is unmodified, and doesn't even know
 that it's hidden behind the Tor network.
 
 As far as Alice's experience goes, we require that her client interface
@@ -1119,12 +1121,13 @@
 design differs from ours in the following ways though. Firstly, Ian
 suggests that the client should manually hunt down a current location of
 the service via Gnutella; whereas our use of the DHT makes lookup faster,
-more robust, and transparent to the user. Secondly, the client and server
-can share ephemeral DH keys, so at no point in the path is the plaintext
+more robust, and transparent to the user. Secondly, in Tor the client
+and server can share ephemeral DH keys, so at no point in the path is
+the plaintext
 exposed. Thirdly, our design is much more practical for deployment in a
 volunteer network, in terms of getting volunteers to offer introduction
-and meeting point services. The introduction points do not output any
-bytes to the clients. And the meeting points don't know the client,
+and rendezvous point services. The introduction points do not output any
+bytes to the clients, and the rendezvous points don't know the client,
 the server, or the stuff being transmitted. The indirection scheme
 is also designed with authentication/authorization in mind -- if the
 client doesn't include the right cookie with its request for service,
@@ -1343,4 +1346,4 @@
 %
 %     'Substitute ``Damn'' every time you're inclined to write ``very;'' your
 %     editor will delete it and the writing will be just as it should be.'
-%     -- Mark Twain
\ No newline at end of file
+%     -- Mark Twain