Comments on latest draft

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

Hi, all.  Here are my comments on George's latest draft.  (In case you
haven't seen it, it's now in Mixminion CVS.  I've placed a copy at
http://www.wangafu.net/nickm/mixminion/MixMin-arch-2.tex)  

I think we're making some real progress here, but there are some things
that I think we need to thwack on before we're ready to write this
server.

0. (I'm skipping comments on the motivations and attacks sections;
that's somebody else's expertise.)

1. Scope: As near as I can tell, this document needs to specify some
other parts to be complete.  We may want to separate the following into
their own sections:
    - Administration (requesting and transmitting server info blocks)
    - Transport
    - Standard delivery methods (including multipart, gzip, dummy, and
smtp) 

   (I know people have said that standard extensions shouldn't be part
of the core spec.  This is right, but we do need to specify them, else
our system is a useless academic exercise.)

2a. We should specify a specific PRNG. 
 b. Why is the PRNG seed gone from the header?

3. Along with the list of rejected design decisions, there should be a
reason why.

4. MH format: 
   a. Sometimes the document says "Main Header", sometimes "Master
Header".
   b. If time is in days, an 8-byte timestamp will last for about 5e16
years - quadrillions of years after the sun burns out.  I think we can
be content with 2 or 3 bytes here.
   c. Return level, reuse level: see 5 below.
   d. Address type, next address, port:  According to this scheme, it
seems that only static addresses are supported.  (20 bytes is far too
short to hold a typical.fully-qualified.hostname.)  Is this a feature,
or a bug?
   e. The fields (size, type, return level) only  make sense for final
headers.  The fields (address type, next address, dest port, expected
key) only make sense for intermediate headers.
      Is this correct?
   f. When last we met, we suggested that "type" be a string, and not be
in the header.  Now it's 2 bytes in the header.  Any reason why?
    
5. BIG ISSUE: It looks like multi-use reply blocks (MURBs) are back in. 
The problem is: I still don't think they work.
   a. If I'm reading the spec right, we use the same IV for every pass
through the system.  This results in multiple uses of counter-mode with
the same IV: a trivially exploitable flaw.
   b. We were trying last time (it seems) to find a good way to build
MURBs without adding a separate "type-1 remailer" mode to our system.  I
think this should still be a goal: traffic of this kind will be
colossally vulnerable to traffic analysis by hostile nodes if it is so
readily distinguishable from the rest of the traffic through the system.
      At the very least, we should acknowledge as a goal the desire to
take this feature out of the system.
   c. Why have a separate field in the MH for reuse level?  Why not just
introduce another message type for type-1 remailer reply, if we're going
to support both modes?  This way, we could specify another encryption
mode for these messages, and avoid (a) above.

6. More issues around the MH section:
   a. For a parameter P, if my understanding (that it's an unrestricted
byte stream) is correct, here are a couple of ideas:
      - Evocative: "But who is that on the other side of you?" (from
"The Waste Land").
      - Political: "Everyone has the right to freedom of opinion and
expression; this right includes freedom to hold opinions without
interference and to seek, receive and impart information and ideas
through any media and regardless of frontiers." (from the Universal
Declaration of Human Rights, article 12)
      - Political #2: "He who would make his own liberty secure, must
guard even his enemy from oppression; for if he violates this duty, he
establishes a precedent that will reach to himself." (Thomas Paine)
      - Any other thoughts?
   b. For "Which format exactly do we want [the date] to be?" I
recommend whole days since Jan 1, 1970, GMT.
   c. I disagree with the proposal for smaller packets. Let's go with
what we have, and change it only if it turns out to work poorly.
   d. For message, we should define at least a "DROP" type as well as a
"FORWARD" type.  We should define a standard name for each type. 
Finally, we should mention the existence of standard extensions. (Like
multipart and smtp.)

7. I'm skipping over the actual examples; they look okay to me, given
what's been said above.  There should also be examples for generating
SURBs (and MURBs, if they exist), using them, and receiving reply
messages.

8. Transport issues: I favor an SSL-based solution.  Designing protocols
and implementing them securely is hard.  (I omit comment on the non-ssl
MMTP, since I'm not competent to analyze it.)
   - There should also be a standard port.

9. Administrative issues: 
   a. The capabilities block needs to be better specified. I'd recommend
a list of supported message types, and leave it at that.
   b. Why <LFCR>?  Is that just a notation for "platform-appropriate
newline," or do you mean something else?
   c. There should be a standard way IMO to query a server's public key
from the server.

Yours,
-- 
Nick