General issues before I leave

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

Dear all,

Here are some issue that are general enough either not be be in the spec 
yet, or to be scattered across the spec.

Link padding Dummy traffic, and mixing Strategies.

All of these are open research questions, and I do not think we should yet 
include them in the spec. Given that we provide mechanism to do them (in 
MMTP, DUMMY in the sub header, no reliance on a particular mixing scheme) we 
should think about them a bit more and maybe issue advice on the best 
practices.

SMTP issues:

We have included the SMTP delivery mechanism. As I understood it it was 
intended for receiving SURB addressed messages without having a server 
always on. In the document it seems that now this is considered a general 
mechanism to deliver SMTP. I think that we should think a bit harder about 
SMTP and produce another spec on SMTP sending/receiving/nyms that I will 
be quite happy to do in August. For the moment I think that most open 
issues involving SMTP in the spec can be solved if we assume that they are 
only going to be used with the last hop of SURBS.

Directory servers.

We must specify a way of querying the mix servers directly about their 
specifications. This could be done as a LOCAL/Directory protocol (that 
could allow people to ask anonymously) or completely separately.
We must include more red-tape information on the description block: ID, 
date, serial number. We can also include a section about what the world, 
in particular its neigbouring servers that it is allowed to connect to. 

The above allows clients and directory servers to query nodes 
automatically, and also allow clients to discover the network by 
themselves (mitigates the problem of load on the Directory server and the 
traffic analysis problems that came with it).

Programming interface:

A clear programming interface must be provided for people making modules. 
For example it is important to distinguish between recipient anonymous 
messages received and others.

Standard for reliable, bi-directional, multi packet communications.

Even before we specify a nym server it might be worth defining standard 
ways of specifying the SURBs that replies should be addressed to, ways of 
performing error correction (using n out of m shares), and how to make 
messages that span across many packets effectively. This is more 
engineering but also have components of traffic analysis resistance in it.

In conclusion:

I am very happy with how the spec looks overall, and I have put a comment 
otherwise. I really think that we should finalize the spec as soon as we 
can and resist the temptation to include any service specific information 
in it. It should describe waht all nodes in the network do, and be as 
simple as possible: remember the bottleneck is to find people running 
servers not to write clever software for the service providers and 
clients.

Next steps: 
Research: Padding (link or dummy), mixing, network topology
Documents: Nym Servers, full SMTP spec, Reliable comms.
Software: client proxies, applications, MixMaster integration

Yours,

George