[or-cvs] clean up dirserver section

[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:
clean up dirserver section


Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.69
retrieving revision 1.70
diff -u -d -r1.69 -r1.70
--- tor-design.tex	3 Nov 2003 02:09:31 -0000	1.69
+++ tor-design.tex	3 Nov 2003 02:25:04 -0000	1.70
@@ -300,8 +300,8 @@
 attacker only needs to observe both ends of the cascade to bridge all
 the system's traffic.  The Java Anon Proxy's design provides
 protection by padding between end users and the head of the cascade
-\cite{web-mix}. However, it is not demonstrated whether current
-implementation's padding policy hinders bridging.
+\cite{web-mix}. However, it is not demonstrated whether the current
+implementation's padding policy improves anonymity.
 
 PipeNet \cite{back01, pipenet}, another low-latency design proposed at
 about the same time as the original Onion Routing design, provided
@@ -1036,51 +1036,46 @@
 We also worry about attacks to deceive a
 client about the router membership list, topology, or current network
 state. Such \emph{partitioning attacks} on client knowledge help an
-adversary with limited resources to efficiently deploy those resources
+adversary to efficiently deploy resources
 when attacking a target.
 
-Instead of flooding, Tor uses a small group of redundant, well-known
-directory servers to track changes in network topology and node state,
-including keys and exit policies.  Directory servers are a small group
-of well-known, mostly-trusted onion routers.  They listen on a
-separate port as an HTTP server, so that participants can fetch
-current network state and router lists (a \emph{directory}), and so
-that other onion routers can upload their router descriptors.  Onion
-routers now periodically publish signed statements of their state to
-the directories only.  The directories themselves combine this state
-information with their own views of network liveness, and generate a
-signed description of the entire network state whenever its contents
-have changed.  Client software is pre-loaded with a list of the
-directory servers and their keys, and uses this information to
-bootstrap each client's view of the network.
+Tor uses a small group of redundant, well-known onion routers to
+track changes in network topology and node state, including keys and
+exit policies.  Each such \emph{directory server} also acts as an HTTP
+server, so participants can fetch current network state and router
+lists (a \emph{directory}), and so other onion routers can upload
+their router descriptors.  Onion routers periodically publish signed
+statements of their state to each directory server, which combines this
+state information with its own view of network liveness, and generates
+a signed description of the entire network state. Client software is
+pre-loaded with a list of the directory servers and their keys; it uses
+this information to bootstrap each client's view of the network.
 
-When a directory receives a signed statement from and onion router, it
-recognizes the onion router by its identity (signing) key.
-Directories do not automatically advertise ORs that they do not
-recognize.  (If they did, an adversary could take over the network by
-creating many servers \cite{sybil}.)  Instead, new nodes must be
-approved by the directory administrator before they are included.
-Mechanisms for automated node approval are an area of active research,
-and are discussed more in section~\ref{sec:maintaining-anonymity}.
+When a directory server receives a signed statement from an onion
+router, it recognizes the onion router by its identity key. Directory
+servers do not automatically advertise unrecognized ORs. (If they did,
+an adversary could take over the network by creating many servers
+\cite{sybil}.) Instead, new nodes must be approved by the directory
+server administrator before they are included. Mechanisms for automated
+node approval are an area of active research, and are discussed more
+in Section~\ref{sec:maintaining-anonymity}.
   
-Of course, a variety of attacks remain. An adversary who controls a
-directory server can track certain clients by providing different
-information---perhaps by listing only nodes under its control
-as working, or by informing only certain clients about a given
-node. Moreover, an adversary without control of a directory server can
-still exploit differences among client knowledge. If Eve knows that
-node $M$ is listed on server $D_1$ but not on $D_2$, she can use this
-knowledge to link traffic through $M$ to clients who have queried $D_1$.
+Of course, a variety of attacks remain. An adversary who controls
+a directory server can track certain clients by providing different
+information---perhaps by listing only nodes under its control, or by
+informing only certain clients about a given node. Even an external
+adversary can exploit differences in client knowledge: clients who use
+a node listed on one directory server but not the others are vulnerable.
 
-Thus these directory servers must be synchronized and redundant. The
-software is distributed with the signature public key of each directory
-server, and directories must be signed by a threshold of these keys.
+Thus these directory servers must be synchronized and redundant.
+Valid directories are those signed by a threshold of the directory
+servers.
 
 The directory servers in Tor are modeled after those in Mixminion
 \cite{minion-design}, but our situation is easier. First, we make the
-simplifying assumption that all participants agree on who the
-directory servers are. Second, Mixminion needs to predict node
-behavior, whereas Tor only needs a threshold consensus of the current
+simplifying assumption that all participants agree on the set of
+directory servers. Second, while Mixminion needs to predict node
+behavior, Tor only needs a threshold consensus of the current
 state of the network.
 
 Tor directory servers build a consensus directory through a simple
@@ -1089,7 +1084,7 @@
 servers; then in round two, each server rebroadcasts all the signed
 opinions it has received.  At this point all directory servers check
 to see whether any server has signed multiple opinions in the same
-period. If so, the server is either broken or cheating, so the protocol
+period. Such a server is either broken or cheating, so the protocol
 stops and notifies the administrators, who either remove the cheater
 or wait for the broken server to be fixed.  If there are no
 discrepancies, each directory server then locally computes an algorithm
@@ -1101,26 +1096,21 @@
 signature is not included on the final directory.
 
 The rebroadcast steps ensure that a directory server is heard by
-either all of the other servers or none of them, assuming that any two
-directory servers can talk directly, or via a third directory server
-(some of the
-links between directory servers may be down). Broadcasts are feasible
-because there are relatively few directory servers (currently 3, but we expect
-to transition to 9 as the network scales). The actual local algorithm
-for computing the shared directory is a straightforward threshold
-voting process: we include an OR if a majority of directory servers
-believe it to be good.
+either all of the other servers or none of them, even when some links
+are down (assuming that any two directory servers can talk directly or
+via a third). Broadcasts are feasible because there are relatively few
+directory servers (currently 3, but we expect as many as 9 as the network
+scales). Computing the shared directory locally is a straightforward
+threshold voting process: we include an OR if a majority of directory
+servers believe it to be good.
 
 To avoid attacks where a router connects to all the directory servers
 but refuses to relay traffic from other routers, the directory servers
 must build circuits and use them to anonymously test router reliability
 \cite{mix-acc}.
 
-When Alice retrieves a consensus directory, she uses it if it
-is signed by a majority of the directory servers she knows.
-
-Using directory servers rather than flooding provides simplicity and
-flexibility. For example, they don't complicate the analysis when we
+Using directory servers is simpler and more flexible than flooding.
+For example, flooding complicates the analysis when we
 start experimenting with non-clique network topologies. And because
 the directories are signed, they can be cached by other onion routers.
 Thus directory servers are not a performance
@@ -1769,7 +1759,7 @@
 Second, if clients can no longer have a complete
 picture of the network at all times, how can should they perform
 discovery while preventing attackers from manipulating or exploiting
-gaps in client knowledge?  Third, if there are to many servers
+gaps in client knowledge?  Third, if there are too many servers
 for every server to constantly communicate with every other, what kind
 of non-clique topology should the network use?   Restricted-route
 topologies promise comparable anonymity with better scalability