Re: API (was: "FORWARD" module)

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

On 27 Mar 2002, Nick Mathewson wrote:

> On Wed, 2002-03-27 at 10:15, Zooko wrote:
>  [...]
> > In particular, I suggest that the mix core spec has only a few types: FORWARD, 
> > DROP, APPLICATION, and perhaps INFO and PING and that there is a separate layer 
> > which encodes arbitrary-length strings as "extension type".  The primary value 
> > of this approach is that the Mix Core stuff which can affect privacy and which 
> > application programmers touch is separate in specification and in implementation 
> > from the extensible part.  (Although I fully agree that v1.0 must specify and 
> > implement SMTP and other extensions!)
> 
> I agree, mostly.  I only worry about "separate in specification": I
> believe our spec, even from the first version, should include these
> extensions as an appendix.  If we're all okay on this, I'd be mostly
> fine....

I am quite happy about the appendix format. I would suggest we specify the 
"system" modules in the main document (INFO, DROP, FRAGMENT, etc) and the 
application in the appendix (SMTP)

>         (BIG QUESTION)
> ...but I'm still worried about the problem that got us onto this track:
> How can SURBs work with fragments?  If anybody can explain this, I'd be
> happy.  (For that matter, how do you specify your email address in a
> SURB?)

The original idea was:

The createtor of the SURB ties the SURB to a particular module that it is 
going to be handled by when it is received. Therefore it is possible that 
the type is set to be "FRAGMENT" and is treated as such by the receipient. 
Of course when the fragments are reconstructed together the result could 
be pipped to another module or application.

The point is that we should not allow the sender to specify that the 
message should be handled by the SMTP module of the receiver (or any 
other module with visible side effects). If it is allowed a trivial 
attack to deanonymise them would be to send a message asking to send 
an email to the attacker. 

>  
>         (LITTLE QUESTION)
> [BTW, does anybody mind the potential for homophonic confusion between
> SURBs and Serbian people?  If so, we should pick a new name or
> abbreviation ASAP.]
> 

The proper term to refer to the serbian people is "serbian". The term 
"serb" has been used extensivly in the UK media during the latest 
interventions to dehumanise serbian people and their cultural attache here 
was not impressed by it at all. I do not think that there is a phonetic 
conflit here.

> I think using MIME would introduce more problems than it solved.
> 
> First, MIME is kinda big.  For instance, there is no reason I can tell
> to process multipart messages in the MIME sense; or to allow different
> character sets.  Also, it is an unthinkably large security hole to ever
> use the environment/OS's underlying MIME handlers.  Therefore, if we use
> MIME, we would probably only want a subset of it.  In other words, every
> payload could be a MIME message, without every MIME message being a
> payload.
> 
> **But the _major_ problem with MIME is that there's more than one way to
> spell it.**  For example, if your client writes 'charset=us-ascii' and
> mine writes 'charset="us-ascii"', our clients are now distinguishable.  
> If we use MIME, we'll need to constrain the spelling as much as we can. 
> You know RFCs 2045-2049 better than I, I'd bet.  What would MIME buy us
> other than conformance to a standard?  (Keep in mind that the standard
> wouldn't allow us to use existing MIME code unmodified, since we'd need
> to make sure it confirmed to the single-spelling subset we allowed.)

I agree with the above. MIME is large and has default visible side effects 
(such as ftp access) which are going to be a nightmare to filter out (and 
even if we do no other implementation will get it right until version 4). 
I suggest we stick with a simpler general message format. Of course if we 
are transporting normal mail (RFC 2822 (Mail), RFC 2821(SMTP)) then it can 
be in any format that a mail client would accept (modulo the side effects 
that will have to be removed by an appropriate user filter).

Yours,

George