mix minion meeting notes by Zooko and Nick

[zooko@zooko.com]

These are my notes that I took at the meeting, plus some more comments that 
I thought of plus some comments from Nick.  You've probably already received 
this, but now it will enter the archives.

--Z

------- Forwarded Message

To: nickm@alum.mit.edu, arma@mit.edu, george.danezis@cl.cam.ac.uk,
    dm@scs.cs.nyu.edu
From: Zooko <zooko@zooko.com>
Subject: Mix Minion meeting notes by Zooko (with Nick)
Date: Sat, 09 Mar 2002 14:52:38 -0800


*** goals (`o') and non-goals (`x')

 o anonymity (as strong as we can make it)
 o replies
 o many nodes (and to that end, the following three:)
 o good user interface
 o reliability
 o abuse/DoS-resistance
   * no immortal packets
 o can be observed, analyzed, for design feedback, science
 o thorough design doc and justification
 o specification so that others can write secure and compatible implementations
 o simplicity and conservative techniques
 o it is possible to build apps on top of the mixnet (they use the messaging 
   services programmatically)
 o long-lived pseudonymous addresses

 x very-low-latency, "synchronous" service
 x eternity service
 x backwards compatible with MixMaster
 x choose your favorite symmetric cipher, etc.
 x fancy, novel techniques
 x extending the mixnet
   * For anonymity we don't want heterogenous behavior within the mixnet.
   * Zooko and Nick don't want the design to be complicated in pursuit of 
     "extensibility" or over-abstraction.
   * Nick and Zooko think that the way to enable evolution of code base is to 
     keep it simple and let people patch it.

*** open issues

 * HOW DOES THE USER LEARN ABOUT NODES AND CHOOSE TO USE THEM?  How does the 
   user agent find out current encryption public keys for the chosen nodes?  If 
   the user or his agent need to know something about the services offered by 
   nodes (such as whether they are "egress" SMTP servers or not), how does he 
   learn about that?
 * David's dynamic-address-generator idea
 * the trade-offs between single-reply-blocks-only vs. multiple-reply-blocks
   The optional-multiple-reply-blocks feature has good (`+') and bad (`-') 
   consequences:
   + The user can receive asynchronous incoming mail without doing any of the 
     following:
     1.  "check for new mail"
     2.  leave a bunch of reply blocks out
     3.  let a daemon check for new mail for her
   + Nymservers can store a fixed amount of storage (one long-lived reply block) 
     per client, rather than storing either an amount of storage proportional to 
     the volume of incoming-and-not-yet-popped mail (in the case of popping) or 
     proportional to the expected number of incoming mail (in the case of a 
     bunch of single-use blocks).
   + The information about the timing of the user being connected to the 
     Internet and ready to receive mail is not exposed.  (Other techniques such 
     as daemons or extra-slow messages might help.)
   ? but what happens when nymserver pushes mail but receiver is off-line?
   ? reliability
   - If there are also one-use reply blocks then nodes can distinguish between 
     kinds of traffic.
   - Multiple-reply blocks are more susceptible to the transitive rubberhose 
     attack.
   - Multiple-reply blocks are more susceptible to replay attacks, in ways that 
     we do not fully understand.
   - Multiple-reply blocks don't work with the "counter mode encrypt-or-decrypt" 
     trick, and deterministic padding generation.  (Can this issue be patched?)
   - Supporting multiple-reply blocks is more complex in other ways.
 * timestamp vs. public key encryption key changeover for bounding the 
   replay-prevention buckets (this is mostly of interest to Zooko, who harbors a 
   pervasive hatred of timestamps...)
 * Can there be a document called "How to write applications on top of MixMinion 
   without losing your anonymity For Dummies"?
 * Nick's ideas for "Stuff that might be nice to get a write-up of":
   * a record of ideas that we rejected and why
   * "Why MixMinion?" (and why not MixMaster, Onions, Tarzan, Crowds)


------- End of Forwarded Message