[Fwd: Nick's comments on mixminion draft]

[Nick Mathewson <nickm@alum.mit.edu>]

Hello all.  Most of you should have this, but it should go in the
archives as well.

These comments apply to the draft spec from before our meeting.

-----Forwarded Message-----

Hi, George!  We talked about many of these notes on Saturday, but I
wanted to make sure you had all the comments on the most recent
MixMinion draft that I wrote before the meeting. I'm omitting comments
on stuff that no longer applies.

Organization:
- We should distinguish normative and informational sections of the 
  document.
- It would be good to explicitly specify how we differ from MixMaster 2
  and from the MixMaster 3 draft.
- We should specify an RNG.

Requirements section:
- We should mention the requirement that we resist corrupt or
  compromised nodes.
- The second-to-last requirement (the one beginning "only clients 
  that benefit...") could be rephrased as "No special software is 
  required to receive or to reply to anonymous messages."
- We should add a requirement that "systems based on mixes (such as 
  nymservers) can still work."

Packet format section:
- We need a version number.  I suggest that we specify some range of
  version numbers as reserved for people who want to experiment with
  incompatible implementations.

Forward-path extensions/Security Issues section:
- Instead of "It is not acceptable to send raw data to the final 
  destination," I think we mean "It is not acceptable to _have_ to send
  data to the final destination.

Transport Issues section:
- If any mix supports more than one mix-to-mix transport method, the 
  choice of which method to use should depend only on the capabilities
  of the previous mix.  (For example, if Alice wants to send a message
  through N1, N2, and N3; and if N2 supports both SMTP and TCP, then it
  should be N1's decision which one to use.  Otherwise, an adversary
  could use Alice's link preferences to reduce her anonymity.)

  Personally, I'd just as soon see a V1 that supports only TCP 
  connections, and later amend it to support some firewall-piercing
  method as well.

Yours,
-- 
Nick Mathewson
<nickm@alum.mit.edu>