Thoughts on MixMinion archives

[Len Sassaman <rabbi@quickie.net>]

Hi again,

Here are the notes I took when I was reading the archive. I already
covered the first few points in my last email, regarding:

* Type III remailers

* initial roll-out to the current remailer users

* number of type 1 servers still lingering

* spec documents -- protocol, message format, bcp for remailer apps

I forgot to explicitly mention that it only makes sense that MixMinion
should be the official reference implementation for the Type III system.

* transport layer

I read over your discussion on whether to use TLS or write your own
transport layer protocol from scratch with much amusement, since we had
identical conversations on the Mixmaster-devel list, and came to the same
conclusions as you did. (I also see immediate benefits, since Mixmaster
relies on OpenSSL anyway. It's also worth noting that Ulf Moeller, the
original author of the current Mixmaster codebase, is an OpenSSL dev team
member.)

* one shot at a backwards incompatible change

Lance said in our BOF that he thinks we only get one shot at a backwards
incompatible change to the remailer network, and I agree with him. I'm
stating this, because a lot of the things being discussed are orthogonal
to the core protocol changes, it will be necessary to introduce them at
once to minimize the number of remailer servers out there with
compatibility problems.

* Message sizes and FreeHaven support

At dinner at Mel's, Roger said he thought that 60K sized messages were too
small for use with FreeHaven and would cause security problems because of
the probability of a split message traveling across a completely
compromised chain. (I agree).

Additionally, I think that 60K is far too large for a deployable system
for anonymous mail. George and Roger and I talked about this a bit, and we
dropped the number to ~30K. I just sent out a ping to the remops
list asking if any of the remops would object to running a remailer that
used 30K messages. I'll let you know what I hear back.

(The problem is that bandwidth is expensive, so having the message be as
small as possible would be best. No one has figured out a way for remops
to make money yet, so we have to be careful about that sort of thing.)

* replay attack protection (id log vs. date stamp)

One thing we discussed in the hallways and at the BOF was how Mixmaster
does replay attack prevention. Lance, when originally designing Mixmaster,
opted not to put a time stamp in the message because of the very reasons
that have been discussed on this list already. What he did instead was put
a unique ID under each layer of the message encryption, and the remailer
stores that ID in a log file with a timestamp. After a good long period of
time, the log is cycled and the entry drops off. (No, this is not a
perfect solution, but if the duration could be set by the remop, it could
provide replay protection for years if she had enough disk space for the
log file to grow).

A third suggestion was made during our conversation with Raph at Mel's
Diner. Claudia Diaz suggested using a random time stamp (within a
reasonable range). I also saw mention of a similar suggestion in the
archives, where dummy traffic could be made with random timestamps
(possibly covering the "unreasonable range" (i.e., too short or long a
time for real messages.)

I lean toward going with the way Mixmaster does it, though I could be
convinced otherwise.

* BEAR kicks ass -- where's R. Anderson's paper?

That's a self-explanatory observation. Can someone cite a location for
the paper on BEAR? It's one of the slickest things anyone's ever drawn on
a placemat in front of me. (And can I get a .mov of you making that face
and sound, George?)

* MIME (yuck)

We had this debate as well. I'm in the "MIME is ugly" camp, and I'm glad
that was the outcome of your discussion also.

* random mix (black holes)

Since Mixmaster pulls messages out of the pool at random, there is the
possibility that a message may get stuck in a pool forever. Is there any
way of making sure this doesn't happen, without weakening the system?

* Delivery methods
* http://archives.seul.org/mixminion/dev/Apr-2002/msg00035.html issues

Roger and George told me about the discussion of what to do with messages
when they hit the last hop of the chain. I like the idea of having each
node set its own exit hop policy. It could be "no unauthenticated
delivery" (i.e., the current Mixmaster "middleman" mode), deliver via
mail, deliver via IRP, hold in a pop-box, or user configurable (with a
specified default.)

Since there is an IRP, we could have a retry system similar to SMTP where
if the user/recipient is offline, remailer messages spool for him until he
comes online and starts listening on the IRP port, and it times out
eventually.

The talk in the above mentioned archived message about "SMTP extension
modules" confuses me. Why wouldn't MixMinion just hand off messages to be
delivered by SMTP to the local MTA?

* storing messages -- legal vs. DOS

I know that I personally would not run a remailer that stored the messages
for retrieval on demand by the user on anything but a dedicated system.
The DOS attack potential would be too great.

All of these points lead me to my next one, though:

* cap strings

We need to at some later point think of how we want to allow remailer to
specify the features they offer.

* remixing type I to type II (to type III?)

Currently, Mixmaster has the ability to receive a Type I message and
"remix" it using Type II. Basically, node A takes the Type I message and
wraps it up as though it were a type II message, and sends it on to node
B (assuming it has node B's mix key). Node B unwraps the Type II layer,
then the Type I layer, than remixes it again if it can. Etc. This is an
attempt at keeping the anonymity set as large as possible.

Would we want to do something like that with Type III?

* master/sub keys

We had a proposal to have the next generation of remailers have a
master/sub key system. The master key would be used for signing
(authentication in the TLS session, as well as signing the sub key and/or
possibly other trusted servers). The sub keys would be the encryption
keys.

Well, it didn't take too long before someone else proposed that (since we
were describing PGP) that we just use PGP. I don't particularly like that
idea, since PGP is full of cruft that isn't needed and could be a
potential source of vulnerabilities and engineering difficulties. Lance
confirmed my suspicions at the BOF by explaining some of the technical
problems with using PGP.

I do, however, like this general model. It allows for key rotation to
occur in a much more smooth manner.

* integrated pinger / reputation system

People have been asking for an integrated pinger in Mixmaster for some
time. Of course, this really could be added at any time, but leads me to
the next point, which is

* pings -- should they be distinguishable from real messages? Pros, cons?

Lucky is quoted as wanting to be able to get stats on how many messages
are real, how many are dummy traffic, how many are pings, etc.

The best that one could do, of course, is tell *out of the messages not
passed on to another remailer* what each of the messages it processes are.
Dummy traffic, of course, is trivial to keep track of.

It is my opinion that pings, however, should not have their own class of
message type, for a few reasons.

Mainly, the current pinging system works just fine as it is. A
pinger sends mail to itself through a remailer or remailer chain, and
reports the outcome. If a pinger was instead asking for a pong response
from the server, the server would be able to skew the stats by
prioritizing pings to a greater degree. (Yes, cheating can still occur by
identifying which recipient addresses are pingers, etc. But why make it
easy?)

* Crossover point system is good.
* http://archives.seul.org/mixminion/dev/Apr-2002/msg00030.html
* http://archives.seul.org/mixminion/dev/Apr-2002/msg00037.html

On these points -- I like the system as it was described to Raph at Mel's.
Roger knows exactly what that was -- (the "strip" method in the post
above, correct?)

* number of hops to be secure vs. reliable

There was concern that about having enough header slots that half of that
number would be enough nodes for a secure chain. I think that 8 is a fine
number. Remember, if the chain is so long that it is almost guaranteed to
be unreliable, it doesn't matter that it is secure. People won't use it.

* nym servers

These must be reliable, and easy to use, or else we will never eradicate
Type I nym servers, and thus never eliminate Type I remailers.

* "Pseudo-IMAP" over Mix for split messages with nyms and SURBs

This idea is really slick. We can work this out in more detail after the
underlying mix protocol is completed, but it is what finally convinced me
that a reply-block based persistent nym system was workable.

I am afraid, though, of objections about having the messages stored on the
nym server. There are also a lot of nym and server DOS issues that we will
need to pay very close attention to. I'll detail my ideas on this at a
later, more appropriate, date.

* forward messages must not be generally distinguishable from replies

I'm of this opinion strongly, which is why I like the crossover point
system.

[...]

So, those are my first round of thoughts. I am forgetting quite a bit I
wanted to mention, but this should be a good start.


Thanks,

Len