Re: Lurkers: First draft: call for comments (was Re: Paper deadlines)

[Wouter Slegers <wouter@yourcreativesolutions.nl>]

On Sun, May 05, 2002 at 04:34:03AM -0400, Roger Dingledine wrote:
> On Fri, May 03, 2002 at 05:31:13PM -0400, David Mazieres wrote:
> > I haven't been able to keep up with the mailing list, but I'm happy to
> > read a draft of the paper if you guys want.  Is there anoncvs, or you
> > can do you want to send me postscript of a reasonably complete draft
> > at some point?
> We now have a 'reasonably complete' draft. If you've been lurking on the
> list waiting for something to read (that includes you, Wouter :), then:
Ok, that is my cue :-)

Short introduction: I found the email archives via a link on zooko.com,
was interested in the project and sent a subscribe message (apparently
much to the surprise of Roger :-)). At the request of Roger I've been
lurking and keeping out of the discussions. My background is from a
formal methods CS (Eindhoven University, Dijkstra's doing), did several
years of work for a Dutch government evaluation lab for high-security
products and am now an independant consultant building those products.
I'm hoping to help out mostly from an evaluation standpoint, so expect
lots of devil's advocate arguments from me.

> http://seul.org/~arma/minion-design.ps
My first raw reactions, given the time-pressure:

Overal: The document is hard to read "standalone", i.e. without prior
knowledge of the current discussions about remailers security and
functionality on this list and mixmaster-devel. Besides making it hard
for an interested reader to get up to speed, it also makes for a shakey
foundation as the consensus of the discussions on the mailinglists will
have changed by the time this paper is published. I particularly miss a
discussion on the reasons for developing a new(er) protocol (i.e. what
is currently missing in mixmaster) and a short write-up of the
protocol-parts that are re-used from mixmaster I/II designs. In
particular paragraph 3.1 "Indistinguishable replies" is hard to read
without it.

Section 1 "Introduction": I suggest adding to the argument for
"seperating the core mixing architecture from these higher-level
modules, we can limit their influence on the anonymity properties of the
system", "and allow usage of the Mixminion remailer network for other
uses then anonymous email exchange" or something similiar to describe
the idea that the network may be used for other goals.

Section 2 "Related work" should probably be moved to the end of the
document. It doesn't add to the understanding of mixminion as such, only
to differentiate it (but this is only apparent after you understand
mixminion).

Section 3 "A MIX-net with Secure Replies":
As I said, some recap of the working of mixmaster as reused by mixminion
is nice here, even if only as a picture of the structure.
I prefer reading the attacks prior to the description of the solution,
more in a "this is the problem, and this is the solutions we came up
with"-structure.
The split-leg-description needs some work, I don't think people are
going to understand what you are doing without going to the
mailarchives.
The cover-trash _is_ dummy traffic?

Section 4 "Related design decisions":
I suggest adding "of past traffic" after "decryption notices" as some
countries also have decryption notices that mandate decryption of
current and future traffic which this rekeying cannot guard against.

Paragraph 4.4 "Message expiration, replay prevention and key rotation":
I do not understand why the rekeying frequency and the timeperiod over
which hashes of headers of messages are kept are set equal. It seems to
me that this links the security of a single node against (legal/hack)
compromise of its identity to the security of (partial) information on
the past traffic through that node. Ofcourse t_rekey >= t_hashflush, but I
can imagine flushing the hashes much frequently then longliving identity
keys.
I think we also need to look at the information that these lists of
hashes contains, in particular from the point of defense against legal
attacks (sue for logs).

With kind regards,
Wouter

-- 
Wouter Slegers
Your Creative Solutions
"Security solutions you can trust and verify."