[minion-cvs] yet more minor changes and responses

[arma@seul.org (Roger Dingledine)]

Update of /home/minion/cvsroot/doc
In directory moria.mit.edu:/home/arma/work/minion/doc

Modified Files:
	minion-design.bib minion-design.tex 
Log Message:
yet more minor changes and responses


Index: minion-design.bib
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.bib,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- minion-design.bib	3 Mar 2003 16:37:03 -0000	1.19
+++ minion-design.bib	4 Mar 2003 03:58:00 -0000	1.20
@@ -5,11 +5,9 @@
     year = {2000},
     month = Aug,
     publisher = {USENIX},
-    isbn = { 1-88044-618-9 },
-    location = {Denver, Colorado},
     pages = "85--96",
-    url = "citeseer.nj.nec.com/473267.html",
-    url = "http://www.usenix.org/publications/library/proceedings/sec2000/full_papers/rao/rao.pdf"; }
+    note = {\url{http://www.usenix.org/publications/library/proceedings/sec2000/full_papers/rao/rao.pdf}},
+}
 
 @InProceedings{pfitzmann90how,
     author = "Birgit Pfitzmann and Andreas Pfitzmann",
@@ -395,7 +393,7 @@
   booktitle =   {Principles of Distributed Computing - {PODC} '01},
   year = "2001",
   publisher =   {ACM Press},
-  note = {\newline \url{citeseer.nj.nec.com/492015.html}},
+  note = {\newline \url{http://citeseer.nj.nec.com/492015.html}},
 }
 
 @InProceedings{kesdogan,

Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.105
retrieving revision 1.106
diff -u -d -r1.105 -r1.106
--- minion-design.tex	3 Mar 2003 16:37:03 -0000	1.105
+++ minion-design.tex	4 Mar 2003 03:58:01 -0000	1.106
@@ -1028,7 +1028,7 @@
 \label{subsec:exitpolicies}
 
 One important entry in a node's capability block is its \emph{exit
-policy}, that describes to which address and by which method a mix node is
+policy}, that describes to which addresses and by which methods a mix node is
 prepared to deliver messages. Exit abuse is a serious barrier to
 wide-scale remailer deployment 
 --- rare indeed is the network administrator tolerant of machines that
@@ -1059,7 +1059,8 @@
 by forging an opt-out request from a legitimate user. We use a compromise,
 where all users are assumed to want to receive mail, but each Mixminion
 message arrives with instructions on how to opt out. 
-% XXX Is this true? (in spec or actual implemetation): 
+% XXX Is this true? (in spec or actual implemetation): -GD
+% Not currently, I think. But we need it to be, right?
 Specifically, the
 message includes a secret that must be used to authorize the opt-out. Thus
 adversaries who cannot read the victim's mail cannot forge an opt-out
@@ -1382,6 +1383,8 @@
 for considerable time) first to flush the original honest messages from
 the mix, and again to flush the target message from the mix. 
 % XXXX Is this true? Do we implement or even specify a heartbeat? -GD
+% Not currently. It seems it might help detect attacks though? But then,
+% how can we tell attacks from network outages? Maybe should take out? -RD
 This delay
 can be noticed by the other mixes, because they communicate over TLS
 with a heartbeat to detect delays.
@@ -1500,7 +1503,7 @@
 \begin{itemize}
 \item \emph{Compromise a mix.} Messages traverse multiple mixes, so
 compromising a single mix, even a crossover point, does not gain much.
-\item \emph{Compromise a mix's private key.} Again, `owning' a single mix
+\item \emph{Compromise a mix's private key.} Again, controlling a single mix
 is of limited use. Further, periodic mix key rotation limits the window
 of time in which to attack the next mix in the target message's path.
 \item \emph{Replaying messages.}  Mixes remember header cryptographic