clean up dirserver section

svn:r725

doc/tor-design.tex

@@ -300,8 +300,8 @@ approach aggregates users into larger anonymity sets, but again an
 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
+\cite{web-mix}. However, it is not demonstrated whether the current
-implementation's padding policy hinders bridging.
+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 @@ attackers an opportunity to exploit differences in client knowledge.
 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
+Tor uses a small group of redundant, well-known onion routers to
-directory servers to track changes in network topology and node state,
+track changes in network topology and node state, including keys and
-including keys and exit policies.  Directory servers are a small group
+exit policies.  Each such \emph{directory server} also acts as an HTTP
-of well-known, mostly-trusted onion routers.  They listen on a
+server, so participants can fetch current network state and router
-separate port as an HTTP server, so that participants can fetch
+lists (a \emph{directory}), and so other onion routers can upload
-current network state and router lists (a \emph{directory}), and so
+their router descriptors.  Onion routers periodically publish signed
-that other onion routers can upload their router descriptors.  Onion
+statements of their state to each directory server, which combines this
-routers now periodically publish signed statements of their state to
+state information with its own view of network liveness, and generates
-the directories only.  The directories themselves combine this state
+a signed description of the entire network state. Client software is
-information with their own views of network liveness, and generate a
+pre-loaded with a list of the directory servers and their keys; it uses
-signed description of the entire network state whenever its contents
+this information to bootstrap each client's view of the network.
-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.
 
-When a directory receives a signed statement from and onion router, it
+When a directory server receives a signed statement from an onion
-recognizes the onion router by its identity (signing) key.
+router, it recognizes the onion router by its identity key. Directory
-Directories do not automatically advertise ORs that they do not
+servers do not automatically advertise unrecognized ORs. (If they did,
-recognize.  (If they did, an adversary could take over the network by
+an adversary could take over the network by creating many servers
-creating many servers \cite{sybil}.)  Instead, new nodes must be
+\cite{sybil}.) Instead, new nodes must be approved by the directory
-approved by the directory administrator before they are included.
+server administrator before they are included. Mechanisms for automated
-Mechanisms for automated node approval are an area of active research,
+node approval are an area of active research, and are discussed more
-and are discussed more in section~\ref{sec:maintaining-anonymity}.
+in Section~\ref{sec:maintaining-anonymity}.
   
-Of course, a variety of attacks remain. An adversary who controls a
+Of course, a variety of attacks remain. An adversary who controls
-directory server can track certain clients by providing different
+a directory server can track certain clients by providing different
-information---perhaps by listing only nodes under its control
+information---perhaps by listing only nodes under its control, or by
-as working, or by informing only certain clients about a given
+informing only certain clients about a given node. Even an external
-node. Moreover, an adversary without control of a directory server can
+adversary can exploit differences in client knowledge: clients who use
-still exploit differences among client knowledge. If Eve knows that
+a node listed on one directory server but not the others are vulnerable.
-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$.
 
-Thus these directory servers must be synchronized and redundant. The
+Thus these directory servers must be synchronized and redundant.
-software is distributed with the signature public key of each directory
+Valid directories are those signed by a threshold of the directory
-server, and directories must be signed by a threshold of these keys.
+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
+simplifying assumption that all participants agree on the set of
-directory servers are. Second, Mixminion needs to predict node
+directory servers. Second, while Mixminion needs to predict node
-behavior, whereas Tor only needs a threshold consensus of the current
+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 @@ signs its current opinion, and broadcasts it to the other directory
 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 @@ signatures.  If any directory server drops out of the network, its
 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
+either all of the other servers or none of them, even when some links
-directory servers can talk directly, or via a third directory server
+are down (assuming that any two directory servers can talk directly or
-(some of the
+via a third). Broadcasts are feasible because there are relatively few
-links between directory servers may be down). Broadcasts are feasible
+directory servers (currently 3, but we expect as many as 9 as the network
-because there are relatively few directory servers (currently 3, but we expect
+scales). Computing the shared directory locally is a straightforward
-to transition to 9 as the network scales). The actual local algorithm
+threshold voting process: we include an OR if a majority of directory
-for computing the shared directory is a straightforward threshold
+servers believe it to be good.
-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
+Using directory servers is simpler and more flexible than flooding.
-is signed by a majority of the directory servers she knows.
+For example, flooding complicates the analysis when we
-
-Using directory servers rather than flooding provides simplicity and
-flexibility. For example, they don't complicate 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 @@ signing up many spurious servers?
 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