Re: Comments on minion-spec.txt

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

On Sat, 2003-05-10 at 17:37, George Danezis wrote:
 [...]
> 1) The "modules" support we have could be entirely scrapped and replaced 
> by whatever custom delivery types people are going to think of in the 
> future. Right now the only additional service it offers, in comparison 
> with the message being delivered to a mixminion client is a shared key. 
> Unless clients provide an API to get this shared key (the current one does 
> not) it is pretty useless. It feels that all the functionality could be 
> implemented E2E and module support can therefore be scrapped. 


I'm not sure whether you're arguing against having different routing
types, but here's how I feel: I like having delivery types in place.  We
would probably want to add more types for stuff like usenet, wget, and
so on.  We almost certainly will want a new type for nymserver control.

You can't do all of this stuff E2E: if you want to have different kinds
of exit delivery, you need different kinds of exit addresses.  This
implies either a type field, or (in my imagination) some seriously ad
hoc approaches where certain magic email addresses mean different
things, and some functionality depends on magic inline commands within
the payload.  That way lies Type I.

But conceptualizing these as _modules_ is, on the other hand, an
implementation issue.  Perhaps we could more accurately call the exit
protocol extensible.

> 2) A lot of the code seems to become more complicated because we have a 
> variable length field to describe variable length addressing information. 
> Is that as useful as originally thought? How many of the current remailers 
> use MMTP, and how many use SMTP to talk to each other? 

First, by "a lot of the code", I assume you mean "a lot of the
pseudocode."   Right now, there is *no* SMTP server-to-server
communication, and I'd fight any proposal to add it.

> Would it just be simpler if only the last sub header could contain a
> "long"  email address (This can be done painlessly since the last
> sub-header in a header has a lot of free space anyway). That can be
> implemented in a much simpler way. We could still put aside enough space
> even for IPv6 addresses to fit.

Erk.  To what end?  Keep in mind that in terms of _implementation_, the
current approach is not significantly difficult.  The message-processing
code in any working server or client is dwarfed in comparison to all of
the support code needed to actually send and deliver messages.

I can't currently make myself certain that that 16+20+2 bytes is enough
for any delivery address, for all time.  If we were wrong about this
assumption, keep in mind that changing the packet format once we're
deployed is really painful -- far more so than implementing routinglen
ever was or will be.

Also, your proposal here to burn >=12 bytes per hop on unused address
material in order to simplify the complexity of the spec is at odds with
your proposals below, which add complexity in order to save space.

I'll confess that on your points (2) and (3) I'm being total luddite.
:)  If others strongly disagree with me, let's revisit this stuff.

> 3) (The slim-fast cure) 

I think the last time we were considering some of this stuff (at
PET2003) we decided that we needed a cryptographer to look at it before
we passed judgment.

 [...]
> [All the above should really go past OAEP experts before implemeting 
> them]

Agreed.  I _think_ that the first (add the digest to the OAEP parameter)
and the third (use <160 bits of the SHA1 hash) look okay, but the second
( gives me willies.

Still, it may not be the best idea to use these things right near the
edge of their operating ranges.  Even if we can get away with it, it may
be harder to convince other people that we're actually secure.  I
*trust* that our current vanilla OAEP works.  I can't get the same feel
for these modified constructions.  

I'd just as soon back off on all of these.

> 4) Question: is it possible to implement an IPv6 server from the spec? 
> (even if there are difficulties talking to the IPv4 world.)

Yes, I believe so, but there isn't any way to advertise it in the
directory.  Neither is there a way specified to build a path using it.

HTH,
-- 
Nick