[or-cvs] clean up bib; remove incorrect directory consensus discussion

[Roger Dingledine]

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

Modified Files:
	tor-design.bib tor-design.tex 
Log Message:
clean up bib; remove incorrect directory consensus discussion


Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -d -r1.31 -r1.32
--- tor-design.bib	17 May 2004 09:07:08 -0000	1.31
+++ tor-design.bib	18 May 2004 06:14:29 -0000	1.32
@@ -91,7 +91,7 @@
 
 @inproceedings{eax,
   author = "M. Bellare and P. Rogaway and D. Wagner",
-  title = "The EAX Mode of Operation: A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency",
+  title = {The {EAX} Mode of Operation: A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency},
   booktitle = {Fast Software Encryption 2004},
   month = {February},
   year = {2004},
@@ -258,7 +258,7 @@
 @InProceedings{sybil,
   author = "John Douceur",
   title = {{The Sybil Attack}},
-  booktitle = "Proceedings of the 1st International Peer To Peer Systems Workshop (IPTPS 2002)",
+  booktitle = "Proceedings of the 1st International Peer To Peer Systems Workshop (IPTPS)",
   month = Mar,
   year = 2002,
 }
@@ -915,7 +915,7 @@
   title = {Passive Attack Analysis for Connection-Based Anonymity Systems}, 
   author = {Andrei Serjantov and Peter Sewell}, 
   booktitle = {Computer Security -- ESORICS 2003}, 
-  publisher =   {Springer-Verlag, LNCS (forthcoming)},
+  publisher =   {Springer-Verlag, LNCS 2808},
   year = {2003}, 
   month = {October}, 
 }
@@ -1014,7 +1014,7 @@
 @InProceedings{p5,
   author =       {Rob Sherwood and Bobby Bhattacharjee and Aravind Srinivasan},
   title =        {$P^5$: A Protocol for Scalable Anonymous Communication},
-  booktitle =    {2002 IEEE Symposium on Security and Privacy},
+  booktitle =    {IEEE Symposium on Security and Privacy},
   pages =        {58--70},
   year =         2002,
   publisher =    {IEEE CS}

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.158
retrieving revision 1.159
diff -u -d -r1.158 -r1.159
--- tor-design.tex	18 May 2004 05:34:45 -0000	1.158
+++ tor-design.tex	18 May 2004 06:14:29 -0000	1.159
@@ -1379,39 +1379,16 @@
 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.
-
-% XXXX Do we really want this next part?  It isn't really sound, and
-% XXXX we haven't implemented it. -NM
-Tor directory servers build a consensus directory through a simple
-four-round broadcast protocol.  In round one, each server dates and
-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. 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
-(described below)
-on the set of opinions, resulting in a uniform shared directory. In
-round three servers sign this directory and broadcast it; and finally
-in round four the servers rebroadcast the directory and all the
-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, 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.
+state of the network. Third, we assume that we can fall back to the
+human administrators to discover and resolve problems when a concensus
+directory cannot be reached. Since there are relatively few directory
+servers (currently 3, but we expect as many as 9 as the network scales),
+we can afford operations like broadcast to simplify the consensus-building
+protocol.
 
 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
+must also build circuits and use them to anonymously test router
 reliability~\cite{mix-acc}. Unfortunately, this defense is not yet
 designed or
 implemented.