Re: Comments on latest draft

[George Danezis <gd@theory.lcs.mit.edu>]

Nick, and all,

Thanks for the comments and the latexed version. I mostly agree with your 
comments (and the amendments on the second email), I hope some of my 
comments will clarify some issues.

On 25 Mar 2002, Nick Mathewson wrote:
> 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.)
> 

I think it is fundamental to specify a default transport mechanism, 
between mixes. This is probably going to be SSL with frequent but 
inexpensive key changes.

I agree that we need a bit more for the administration, and in particular 
standard ways of describing capabilities and keys.

I agree that we need to specify some standard modules that everyone should 
implement. DUMP is one of them, PING might be another (any other ideas?).

Finally on to of all this we should define a standard application (such as 
email) as a proof of concept and so that people start using it.

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

The Master Secret on the Header can be transformed to seed a PRNG. 

Note that we do not define a mixing method in the standard. I am not sure 
how prudent that is. Maybe we should require a minimum level of traffic 
and mixing from each node.

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

Yes we should.

> 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?

This is a feature. We are working at the network layer so the mixes on the 
path do not need to do DNS queries. I agree that we are in trouble if IPv6 
catches on with dynamic addresses. Having variable length addresses will 
be a traffic analysis nightmare, unless we allocate a fixed but large 
size.

>    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?

Type is used to tell the mix if the message is to be re injected, so it is 
useful to intermediate hosts. Return level can also be used by 
intermediate nodes to perform a more secure encryption operation than 
Counter mode with a fixed IV for MURBs. I do not describe this since I am 
not sure if we want MURBs at all.

>    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?
>     

This is a basic multiplexing mechanism to facilitate the job of the server 
logic that redirects the packet to the appropriate module for processing. 
You can think of it like the protocol type in IP headers or the Port type 
of TCP/UDP. The message body can then contain any additional configuration 
information specific to the module.

> 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.

I have been thinking of MURBs a lot. Basically they do not work even under 
the most weak threat model assumptions. I agree that counter mode does not 
make things better but after some though I have convinced myself that it 
does not make things worse either. Intermediate nodes are always able to 
see their position in the chain (which is always the same), they can link 
messages together (they must have the same header). They can also tag 
messages and follow them through the mix network.

I increasingly think they are a truly bad idea, because they seem so 
convenient. People are going to use them instead of building proper 
systems, offering strong anonymity.

> 
> 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?

I quite like Political #2. Political #1 has the problem that it also  
contains:

Article 12.

No one shall be subjected to arbitrary interference with his 
privacy, family, home or correspondence, nor to attacks upon his honor 
and reputation. Everyone has the right to the protection of the law 
against such interference or attacks.

>    b. For "Which format exactly do we want [the date] to be?" I
> recommend whole days since Jan 1, 1970, GMT.

I think this should be fine.

>    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.

ok.

>    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.)

Yes we should.

> 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.
> 

I quite favor the SSL based solution myself, given that it offers us 
everything we need. We should restrict its ability to negotiate week 
combinations of ciphers.

> 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.

Who want to rework these?

Yours,

George