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

[minion-cvs] Last round of content questions.



Update of /home/minion/cvsroot/doc
In directory moria.seul.org:/tmp/cvs-serv25453

Modified Files:
	minion-design.tex 
Log Message:
Last round of content questions.

Index: minion-design.tex
===================================================================
RCS file: /home/minion/cvsroot/doc/minion-design.tex,v
retrieving revision 1.85
retrieving revision 1.86
diff -u -d -r1.85 -r1.86
--- minion-design.tex	6 Nov 2002 04:18:24 -0000	1.85
+++ minion-design.tex	6 Nov 2002 04:33:46 -0000	1.86
@@ -203,6 +203,10 @@
 % i don't think it's a big deal to the academic folk. they certainly
 % don't care what some version of some piece of software intends to
 % do. let's leave it subtle. -RD
+%   Okay.  My concern is keeping other people from getting confused,
+% but if you think we're clear enough... -NM
+%
+% XXXX Mention that we have code and preliminary performance results? -NM
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -287,7 +291,7 @@
 and other mix features lacking in the Cypherpunk remailers.
 
 \subsection{Known attacks against mix-nets}
-% ???? Move this to the end of section 3?
+% ???? Move this subsection to the end of section 3?
 
 Attacks against mix-nets aim to reduce the anonymity of users by
 linking anonymous senders with the messages they send, by linking
@@ -466,14 +470,11 @@
 and it is therefore difficult to partition the anonymity sets by
 distinguishing between them. 
 
-
 % replies: we want to avoid partitioning by having reply messages be
 %   indistinguishable from forward messages, and just as secure.  To the
 %   extent possible, a mix should not be able to learn any more from a
 %   message's contents than from the fact of the message's receipt.
 
-
-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \section{The Mix-net Design}
@@ -952,10 +953,12 @@
 \label{subsec:delivery-modules}
 
 %XXXX
-[I think it is important to say what modules get us in comparison to
-normal client side Mixminion (which servers can also use). In
-particular, access to some shared key material and plug-in for
-infrastructure critical services. -GD]
+%[I think it is important to say what modules get us in comparison to
+%  normal client side Mixminion (which servers can also use). In
+%  particular, access to some shared key material and plug-in for
+%  infrastructure critical services. -GD]
+%[Most significantly IMO is that modules can be advertised via the
+%  regular capabilities mechanism. -NM]
 
 Once a Mixminion packet reaches the final mix in its path, it must
 either be delivered to its intended recipient, dropped if it is an
@@ -968,7 +971,7 @@
 implement abuse-resistant exit policies (see Section
 \ref{subsec:exitpolicies}), to administer nymservers (see Section
 \ref{sec:nymservers}), to publish anonymously to Usenet, to relay
-messages to older remailers, or to support other protocols.
+messages to older remailers, or to support other protocols.  
 
 Nearly all delivery methods require additional information beyond the
 message type and its payload.  The SMTP module, for example, requires
@@ -1161,6 +1164,9 @@
 
 \section{Directory Servers}
 \label{sec:dir-servers}
+%XXXX Motivate this a bit earlier; be explicit about why ad hoc
+%      schemes are unacceptable. (Not just because of partitioning,
+%      but also because of support for rotation.) I can write this. -NM
 
 The Mixmaster protocol does not specify a means for clients to learn the
 locations, keys, capabilities, or performance statistics of mixes. Several
@@ -1371,6 +1377,11 @@
 % XXXX Huh? Heartbeat? -NM
 % spoke to you about this on the phone. feel free to add clarifying
 % text if you like. there's another place we say heartbeat too. -RD
+% XXXX Ah.  Roger tells me that this means checking for some kind of
+%    regular 'keepalive' along the TLS connection, and suspecting
+%    foul play if it's missing.  I think we may not to make such a
+%    strong claim here; need to think more. -NM
+
 
 This batching strategy also increases the cost of intersection attacks by
 providing large anonymity sets for each message in the network. Because
@@ -1416,7 +1427,9 @@
 created by the adversary.
 
 \subsection{Transmitting many messages}
+%XXXX Rename: ``choosing paths when transmitting many messages'' -NM
 \label{subsec:many-messages}
+%XXXX Mention large messages too. -NM
 
 When Alice (the owner of a pseudonym) downloads her mail from a
 nymserver, she will likely receive many separate messages. Similarly, if
@@ -1579,7 +1592,9 @@
 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, but an all-or-nothing
+\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
@@ -1592,15 +1607,14 @@
 such dummy messages.
 %\item We intend to draw up a more complete specification, which can lead
 %to implementation and deployment of the Mixminion design.
-% We'll have to get another spec cobbled together before anybody can review
-% this system thorougly.  Should we mention some place for people to
-% get a more formal spec?  I wouldn't be able to review our system at
-% the level that I'd want to without one.  -Nick 
+% XXXX Mention our spec?  Cite our spec? -NM
 \end{itemize}
 
 As detailed in the introduction the principal aim has 
 been to include in Mixminion only techniques that are well
-understood. Although some people have speculated about the positive
+understood.
+% XXXX Um... do we even still say that? -NM
+Although some people have speculated about the positive
 effects of the techniques described as open issues above we have not
 yet seen a thorough enough analysis to be convinced. For this reason
 while Mixminion is flexible enough to support them it does not use
@@ -1608,6 +1622,8 @@
 engineering effort to implement the specification into a robust system
 proceeds, undoubtedly the researchers associated or inspired by this
 project will try to shine some light on the open questions above.
+
+% XXXX Mention code and performance? -NM
 
 We invite interested developers to join the {\tt mixminion-dev}
 mailing list and examine the more detailed Mixminion