Thoughts on the remailer network

[Len Sassaman <rabbi@quickie.net>]

Hi folks. Some of you know me fairly well already, and others I just met
at CFP. In short, I'm the current maintainer of Mixmaster. I started out
as a remop, and inherited this position mostly by accident. Since then,
I've been trying to figure out how I can make things better for the
remailer community.

I've read your archive (yes, all of it), and would like to comment on
points brought up in the archives, as well as recap some of my thoughts
regarding the conversations I had with George, Roger, and other wonderful
people at the conference. I've decided to do that in a second follow-up
message, however, and instead start off by explaining my plans for the
remailer network.

I took over Mixmaster a little over six months ago. Since that time, I've
identified a number of problems with the application, the remailer
network, and the protocol that I would like to see fixed.

An updated version of the Mixmaster message format was in the works a
while ago (it's referenced as the "v3" spec online), and I resurrected
interest in introducing an improved Mixmaster format. It was quickly
decided, however, that we should not use the draft v3 spec as it stood.

Also, we wanted an inter-remailer protocol. This has been something that
we've been lacking for a long time -- most remops would be quite happy if
they only had to rely on their MTAs for entrance and (sometimes) exit
traffic, and not for the noise in between. Lance Cottrell started work on
this years ago -- I have an unreleased snapshot of code dated 9-11-1995
with an almost complete inter-remailer protocol implementation #ifdef'd
out. Aside from reliability and compatibility, the IRP would allow us to
introduce a method for providing forward secrecy.

Also, I have wanted to be able to kill off Type I remailers. (Lucky Green
has on several occasions likened running a Type I remailer to entrapment,
but there's little that we can do about that until we have a viable
nym server alternative.) This isn't possible, since there are no Type II
nym servers. At first, I wished to think of a better way of doing
anonymous message receipt, but the necessary primitive that I need for the
system I wish to use doesn't at this time exist. My objection to reply
blocks was mainly due to reliability problems that go hand-in-hand with
MURBs. I hadn't thought of a viable SURB system, but as I'll comment
later, I'm satisfied (nay, delighted) with George's brilliant idea for an
IMAP-like system over the mix. So, I'm content to live with reply-blocks
for now.

There were other issues we wished to address too, but those were the most
pressing. For anyone truly interested, you can dig through the archives of
the mixmaster-devel list on SourceForge (though there is a lot of "I found
a memory leak" type noise on that list as well.)

[...]

As I said earlier, my background is that of a remop. Which means that I
care first and foremost about the security, reliability, and usability of
the anonymous remailer network. I want to do what is best for the network,
and for my users. I am not wedded to any particular mix system, nor do I
have my ego tied up with any particular codebase.

That said, I am going to propose a rough roadmap for the adoption of a new
remailer network protocol and elaborate on my thoughts about the state of
the remailer world.

I suggest that the MixMinion folks differentiate between the protocol and
the application. I think Roger and I agreed that the protocol you have
been working on could be called something like "Type III Remailer
Protocol" or similar. After the design and specifications of the system
you've been working on is peer-reviewed and passes acceptably (which it
looks like it should, given the reception it has earned already), it
should be written up in RFC format and submitted to the IETF.

Adam Shostack suggests that we go forward with this in the NymIP group.
That is certainly a possibility. At this point, I think we would want
three documents: a paper describing the message format and low-level wire
protocols, a paper describing proper behavior of a mix node, and a paper
describing the proper and possible behavior of a nym server.

So, here's one way things could play out that would give you maximum
adoption by the remailer community:

1. Once the message format, protocol, and behavior issues are firmly
decided (though not necessarily after the IETF gets through with them),
the Mixmaster folks add in support for Type III messages into Mixmaster.
At the time of this writing, there are 36 Type II capable remailers
running.  There are only slightly more Type I remailers running, and most
of these are running Mixmaster as well. We add Type III to Mixmaster, and
most of the remops will upgrade to support the new protocol version. This
version will be Mixmaster 3.0.

2. We get Type III nym servers online. I think it is crucial that we get
the LCS folks behind us on this. There are currently 2 other nym servers,
but none with the popularity of nym.alias.net. In fact, it would be
excellent if the LCS folks provided an upgrade path for the current
nym.alias.net holders to migrate to the new system (newnym.alias.net?)

3. We allow enough time for nym account holders to switch to the Type III
system. I'm thinking six months should be okay, though we ought to
evaluate that at the time. Getting stats on usage from nym.alias.net could
help. At this point, I will drop Type I support from Mixmaster.

4. We allow enough time for the client developers to integrate Type III
into their programs. I am particularly concerned about Jack B. Nymble and
Quicksilver. Once this occurs, we drop Type II from Mixmaster.

[Points 3 and 4, if timed correctly, could occur simultaneously. Once both
are gone, we rev to Mixmaster 3.5.]

5. Mixmaster is completely rewritten to support only Type III messages.
This is version 4.0 of Mixmaster.

[...]

All the while, MixMinion (which I understand you are doing in Python)
should be in use, and hopefully be attracting new remops who will be
running Type III only remailers. I'd also like to see MixMinion-based
clients for a wide variety of OSes, particularly ones like MacOS which do
not have decent Type II client support, so that demand for Type III
remailers is high. With MixMinion Type III-only remailers being operated
and heavily used, when it comes time to move to Mixmaster 4.0, there
will be minimal complaining.

Okay, here are the reasons why I think this is a good way of approaching
things:

1. There are already 35+ remops running Mixmaster. Getting them to
upgrade their systems to a new version of Mixmaster has not been too
difficult in the past. Getting them to switch to an entirely new program
out of the blue, or finding 35 new geographically and politically separate
remops to run a new program, will be more difficult. If we can leverage
the existing remailer network, we will have bootstrapped very successfully.

2. It allows for two "genetically different" implementations of the Type
III remailer protocol from the get-go. This is something the IETF will
want to see.

3. Python is a great language, but there will still be people who want C.
I'd like to be able to give them their choice.

4. I have a firm transition plan for phasing out the existing systems. I
particularly wish to do away with Type I as soon as possible.

[...]

I'm compiling a list of thoughts based on the archives of your list, the
remailer BOF at CFP, and the conversations I had with Roger and George,
etc. I'll have that sent to you all shortly. In the mean time, are there
any issues you want to bring up regarding the above proposal?

(Thanks again to all of you for the fine work you've done, too. You have
no idea how happy I am to see what you've done.)



--Len.