[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Comments on minion-spec.txt

On 15 May 2003, Nick Mathewson wrote:

> On Sat, 2003-05-10 at 17:37, George Danezis wrote:
> 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.

I do not have an issue with the routing types that exist (fwr/swap/...), 
just the idea that it might be useful to extend these...

The nym server is a good example of what I am thinking about. In order to 
use the nym server you will need both a nym server, AND a nym client. The 
server is obvious, but I would argue that the complexity of managing 
SURBS, decryption keys and the rest of the security issues do require a 
client that understands the nym protocol. The architecture is therefore 
that the nym server speaks MMTP and receives messages under its public 
key (but does not have to be a mix server), while the nym client sends the 
commands within the nym protocol using type III. I do not see how the 
'Modules' manager would ever get hold of any information. The type III 
system is simply used as an anonymous transport mechanism, and all the 
relevant information to the protocols above it are contained in the higher 
protocols (nym protocol in this case).

When modules were originally conceived I was thinking more in terms of 
implementing different mix strategies, such as sg-mixes, that require 
additional information on top of the addresses, or support different 
inter-mix transport protocols (SMTP was quite entrenched at the time, and 
I also welcome the fact that we have rejected it for this purpose!)

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

Indeed I was refering to the complexity of describing the encoding and 
decoding procedure (the email originally was wrote after having a look at 
the new spec format).
> > 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.

Yes but the security critical code is very much focused there (in case 
someone wants to prove it correct), along with the part that is required 
to get absolutely right to interwork with everyone else. In these two 
respects I think there are advantages in making this simple, particularly 
if we want high confidence and independent implementations. Don't get me 
wrong: I do not think that the spec as it stands do not fulfill these. I 
am just wondering what we get for the additional complexity.

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

You are right. 

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

I am going to look for one, but I do not think any of these are critical. 
It is just interesting for the record to know that if we ever find a good 
reason to slim upu the packets we could.

Thanks for the comments back and I hope IEEE S&P was good.