[or-cvs] patches on nick"s sec4 patches

[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:
patches on nick's sec4 patches


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -d -r1.77 -r1.78
--- tor-design.tex	3 Nov 2003 10:29:18 -0000	1.77
+++ tor-design.tex	3 Nov 2003 12:07:02 -0000	1.78
@@ -531,8 +531,8 @@
 new router. The onion (decryption) key is used for decrypting requests
 from users to set up a circuit and negotiate ephemeral keys. Finally,
 link keys are used by the TLS protocol when communicating between
-onion routers.  Both short-term keys are rotated periodically and
-independantly, to limit the impact of compromised keys.
+onion routers. Each short-term key is rotated periodically and
+independently, to limit the impact of key compromise.
 
 Section~\ref{subsec:cells} discusses the structure of the fixed-size
 \emph{cells} that are the unit of communication in Tor. We describe
@@ -545,7 +545,7 @@
 \SubSection{Cells}
 \label{subsec:cells}
 
-ORs communicate with one another, and with users' OPs, via TLS
+Onion routers communicate with one another, and with users' OPs, via TLS
 connections with ephemeral keys.  This prevents an attacker from
 impersonating an OR, conceals the contents of the connection with
 perfect forward secrecy, and prevents an attacker from modifying data
@@ -556,16 +556,16 @@
 allowing large cells and small cells on the same network), and
 consists of a header and a payload. The header includes a circuit
 identifier (circID) that specifies which circuit the cell refers to
-(many circuits are be multiplexed over the single TLS connection), and
+(many circuits can be multiplexed over the single TLS connection), and
 a command to describe what to do with the cell's payload.  (Circuit
-identifiers are connection-specific; a single circuit has a different
-circID on each connection it uses.)
+identifiers are connection-specific: each single circuit has one circID
+for the forward connection and another for the backward connection.)
 % XXX Say that each OR can have many circuits with same circID, so
 % XXX long as they're on different connections, and that ORs know 
 % XXX which circIDs/connection pairs are linked by a circuit.
 Based on their command, cells are either \emph{control} cells, which are
 always interpreted by the node that receives them, or \emph{relay} cells,
-which carry end-to-end stream data.   The controls cells commands are:
+which carry end-to-end stream data.   The control cell commands are:
 \emph{padding} (currently used for keepalive, but also usable for link
 padding); \emph{create} or \emph{created} (used to set up a new circuit);
 and \emph{destroy} (to tear down a circuit).
@@ -643,20 +643,20 @@
 the circuit is extended to Carol, and Alice and Carol share a common key
 $K_2 = g^{x_2 y_2}$.
 
-In order to extend the circuit to a third node or beyond, Alice
+To extend the circuit to a third node or beyond, Alice
 proceeds as above, always telling the last node in the circuit to
 extend one hop further.
-% XXX Briefly mention path selection.
+% XXX Briefly mention path selection and path length.
 
 This circuit-level handshake protocol achieves unilateral entity
-authentication (Alice knows she's handshaking with Bob/Carol, but
-Bob/Carol doesn't care who is opening the circuit---Alice has no key
+authentication (Alice knows she's handshaking with the OR, but
+the OR doesn't care who is opening the circuit---Alice has no key
 and is trying to remain anonymous) and unilateral key authentication
-(Alice and Bob/Carol agree on a key, and Alice knows Bob/Carol is the
-only other person who should know it). It also achieves forward
-secrecy and key freshness.  Formally, the protocol is as follows
-(Where $E_{PK_{Bob}}(\cdot)$ is encryption with Bob's public key,
-$H$ is a secure hash function, and $|$ is concatenation.)
+(Alice and the OR agree on a key, and Alice knows the OR is the
+only other entity who should know it). It also achieves forward
+secrecy and key freshness. More formally, the protocol is as follows
+(where $E_{PK_{Bob}}(\cdot)$ is encryption with Bob's public key,
+$H$ is a secure hash function, and $|$ is concatenation):
 
 \begin{equation}
 \begin{aligned}
@@ -682,7 +682,7 @@
 % XXX encrypted.  The easiest expository order should probably be: What ORs
 % XXX Do With Unrecognized Streams; What Alice Does To Build Relay
 % XXX Cells; What ORs Do With Streams They Recognize.
-Recall that every relay header has a stream ID in the relay header
+Recall that every relay cell has a stream ID in the relay header
 that indicates to
 which stream the cell belongs.
 This stream ID allows a relay cell to be addressed to any of the ORs
@@ -710,9 +710,9 @@
 node will send a \emph{destroy} cell forward, and reply with an acknowledgment
 (a \emph{relay truncated} cell).  Alice might truncate her circuit so
 she can extend it
-to different nodes without signaling to the first few nodes (or somebody
+to different nodes without signalling to the first few nodes (or somebody
 observing them) that she is changing her circuit. That is, nodes in the
-middle of a truncated are not even aware when the circuit is
+middle of a circuit are not even aware that the circuit has been
 truncated, because they see only the encrypted relay cells.
 Similarly, if a node on the circuit goes down,
 the adjacent node can send a \emph{relay truncated} cell back to
@@ -964,6 +964,10 @@
 \SubSection{Exit policies and abuse}
 \label{subsec:exitpolicies}
 
+%XXX originally, we planned to put the "users only know the hostname,
+%    not the IP, but exit policies are by IP" problem here too. Worth
+%    while still? -RD
+
 Exit abuse is a serious barrier to wide-scale Tor deployment. Anonymity
 presents would-be vandals and abusers with an opportunity to hide
 the origins of their activities. Attackers can harm the Tor network by
@@ -1857,7 +1861,7 @@
   these bottlenecks.
 \item \emph{Cover traffic:} Currently we avoid cover traffic because
   of its clear costs in performance and bandwidth, and because its
-  security benefits have not well understood. With more research
+  security benefits are not well understood. With more research
   \cite{SS03,defensive-dropping}, the price/value ratio may change,
   both for link-level cover traffic and also long-range cover traffic.
 \item \emph{Better directory distribution:} Even with the threshold