[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[minion-cvs] more work on the conclusion



Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/home/arma/work/minion/doc

Modified Files:
	minion-design.tex 
Log Message:
more work on the conclusion


Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.86
retrieving revision 1.87
diff -u -d -r1.86 -r1.87
--- minion-design.tex	6 Nov 2002 04:33:46 -0000	1.86
+++ minion-design.tex	6 Nov 2002 05:11:02 -0000	1.87
@@ -129,18 +129,12 @@
 \item \textbf{Exit policies:} Exit abuse is a serious barrier to wide-scale
 remailer deployment: most ISPs do not tolerate users who potentially
 deliver hate mail, etc. While the original Mixmaster design provided no
-way for mixes to advertise their capabilities and roles (so in practice nodes
-either allowed all outgoing messages or none), 
-%assumed all
-%nodes have identical capabilities and roles (and thus messages can exit
-%from any node),
+way for nodes to advertise their capabilities and roles (so in practice nodes
+either allow any outgoing messages or none), 
 Mixminion allows each node to specify and advertise an exit policy. We
-describe a protocol which allows recipients to opt out of receiving mail
+further describe a protocol which allows recipients to opt out of receiving mail
 from remailers, but at the same time makes it difficult for an adversary
 to deny service to interested recipients.
-% XXXX Actually, Mixmaster allows nodes to -have- different policies:
-%      there's just not a good way to advertise your policies beyond 
-%      simple capabilities. -NM
 
 \item \textbf{Replay prevention and key rotation:} 
 If an adversary records the input and output batches of a mix and then
@@ -292,6 +286,7 @@
 
 \subsection{Known attacks against mix-nets}
 % ???? Move this subsection to the end of section 3?
+% what, the whole subsection? -RD. what would it be doing in sec 3?
 
 Attacks against mix-nets aim to reduce the anonymity of users by
 linking anonymous senders with the messages they send, by linking
@@ -421,10 +416,10 @@
 First of all, the system must be relatively simple to deploy. Past systems
 have never found it easy to get a reliable group of mix operators to
 run long-lived servers. Mixminion must add as few technical barriers as
-possible. Thus our protocol uses only loose clock synchronization (within
-a few minutes), achieves acceptable performance on commodity hardware,
-requires little coordination between servers, and can automatically
-handle servers joining and leaving the system.
+possible. Thus our protocol uses clock synchronization only to notice
+when a mix's key has expired; achieves acceptable performance on
+commodity hardware; requires little coordination between servers; and
+can automatically handle servers joining and leaving the system.
 
 % Client requriements
 Furthermore, software adoption has also been a barrier to past
@@ -479,6 +474,7 @@
 
 \section{The Mix-net Design}
 % ???? Rename to 'The Mixminion Design'? -NM
+% no, because the mixminion design is more than just this section. -RD
 \label{sec:design}
 
 Mixminion uses a free-route mix-net just like \cite{mixmaster-spec}
@@ -1579,32 +1575,28 @@
 design to peripheral design choices, need more attention:
 
 \begin{itemize}
-\item We need more research on batching strategies that resist trickle
-and flooding attacks \cite{batching-taxonomy} as well as intersection
+\item We need more research on batching strategies that resist blending
+attacks \cite{batching-taxonomy} as well as intersection
 attacks on asynchronous free routes \cite{disad-free-routes}. In
-particular the anonymity they provide during normal operation or under
-attack has to be balanced with other properties such as latency and
-queue sizes on the mix servers.
+particular the anonymity they provide during normal operation or
+under attack must be balanced with other properties such as latency
+and reliability.
 \item We need a more thorough investigation of multiple-message tagging
 attacks, and an analysis of how to safely choose paths when
 sending many messages. When a message to be sent is larger than the
-Mixminion payload size there is a need for a strategy to fragment
-it and reconstruct it at the recipient's end. In case some of the
-messages are lost retransmission strategies or forward error
-correction codes can be used to recover the message. 
-\item We claim that we use conservative techniques,
-% XXXX Oops!  We no longer claim this.  What to say here instead?-NM
-but an all-or-nothing
-variable-length block cipher is pushing it. Can we keep indistinguishable
-forward messages and replies using a simpler design? It would be
-relieving if the design can be proven to provide unlinkability between
-the input bit-patterns of messages and the messages coming out of the
-network. 
-\item We need stronger intuition about how to use
-dummy messages. Such messages can be inserted either at the link layer
-or the actual Mixminion layer, and defend against different attacks. A
-more rational approach needs to be developed on who and when to insert
-such dummy messages.
+Mixminion payload size, we need a strategy to fragment
+it and reconstruct it at the recipient's end. 
+We can use retransmission strategies or forward error
+correction codes to recover if some messages are lost.
+\item Can we keep the indistinguishability of forward messages and
+replies using a simpler design? We need to prove that our design provides
+unlinkability between the input bit-patterns of messages and the messages
+coming out of the network.
+\item We need stronger intuition about how to use dummy messages. Such
+messages can be inserted either between nodes as link padding, or as
+actual multi-hop Mixminion messages. We must develop a more rational
+approach to which parties send dummy messages, how many they send,
+and when they send them.
 %\item We intend to draw up a more complete specification, which can lead
 %to implementation and deployment of the Mixminion design.
 % XXXX Mention our spec?  Cite our spec? -NM