Re: General issues before I leave

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

On Fri, 2002-07-12 at 14:32, George Danezis wrote:
> 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.

I agree, so long as this goes into a later version of the mainline
spec.  Padding only works if most people do it. :)

> 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 have always understood SMTP as a general mechanism to deliver SMTP
messages, so that we can support recipients without special software,
and not require deliberate opt-in. 

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

Ulp.  I'd rather try to get the bare bones of SMTP figured out now, even
if we put it in an addendum.  We haven't got the spam/abuse issues
solved yet, and so I'd like to hold off on implementation for a little
while, but it would be good to address this.

BTW, splitting stuff into separate documents is a pretty good idea. :)

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

I still think it's adequate for servers to simply publish their
information; see why below.

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

Client discovery of the network creates tremendous problems.  It allows
for an evil node to partition clients by telling different information
to different clients.

I'll bet that our existing design should scale pretty well, since it
requires a directory server to only (1) check each server periodically,
and (2) serve a static document to each client once per day. Since the
document is signed, we can safely mirror (2) across many servers to make
(2) scale well.  As for (1), a good directory server ought to be able to
generate, transmit, receive, and process about 10,000 8-hop test
messages per hour.  (Assuming non-sucky processor and 100kbyte/sec
connection.)

The real solution is multiple directory servers, which we don't really
know how to do.  So let's not make this tradeoff just yet. :)

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

I'll include an API document to the software.

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

This would be really neat; let's try to get this in the next version.

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

I agree; the distinction needs to be between mandatory features (like
directories, and padding/dummies once we have them) and optional
features.  The latter should probably be moved into appendices or
separate documents.

I think the two of us may disagree on how necessary SMTP is, but I think
we both agree that (1) it needs to get specified well enough to deliver
messages to software-less recipients (2) everyone who provides it should
provide more or less the same thing (else anonymity is imperiled); and
(3) we shouldn't implement it until we understand abuse better.

So if this is the case, let's try to specify it in an appendix as best
we can today, but not implement it until the issues in (3) are more
settled.  Sound okay?

Yours,
-- 
Nick