kevin@elvis.wicat.com:

Be gentle, though - it's my first time.

Here? You jest. ;)

It seems to me that the current remailer web suffers a fundamental flaw. It is simply too static. When a remailer disappears, service is disrupted and messages are lost. Humans have to statically route their messages through the web either by hand or using relatively primitive tools such as the chain script (not to belittle the useful work that has been done, but it is by no means idiot proof yet). Basically, the current web of mailers shows nothing of the dynamic nature that has kept the internet alive and has offered us a decent chance at truly anonymous communications, nor is it easy to use to its full potential.

Consider a more dynamic web of remailers. I envision remailers that actively advertise their presence on the web so that all active remailers are aware of all other active remailers. This advertising is to have very low latency so that a new mailer can be known to the web within minutes (I will address the implementation of this later). Thus, remailers can constantly be appearing and disappearing without impact on the web as a whole (I refer to this dynamic web of remailers as a "froth"). Imagine also that remailers are allowed to dynamically perform the routing functions that are currently done statically offline (for reasons I will discuss shortly).

Some version of this discussion came up a few months ago, and I passed on it then, but I think I've heard enough to comment now: The remailers are based on an inherently different model than the InterNet. Some of these differences, in fact, are crucial. 1) The InterNet is based on mutual cooperation/mutual trust. Cypherpunks trust no one that they don't have to. This is not just a result of our twisted psyche. If we could trust everyone, we wouldn't _need_ remailers. Since we don't even know who is whom out there, we avoid extending trust. 2) The InterNet is concerned first about reliability, and not at all about privacy. The remailers are concerned first about privacy, and can leave reliability to the users, if need be. There is nothing to prevent Alice and Bob agreeing to send each other ACK statements, and retransmitting messages if they don't get the ACK. There has been some mention of remailers doing the same with each other, in an attempt to improve net-wide reliability. BTW, with T1, sending ACKs is not unreasonable between remailers. 3) From 1) and 2). The remailers are heading towards mandatory PGP, possibly nested. All InterNet messages are world-readable--although this may be changing as the model breaks down. Again, this has to do with the intrinsic diffences.

The use of such transient routers implies allowing dynamic routing. If any given remailer may go down or move at any point, it is impractical to expect users to keep track of which are up at the moment and create static routes in the current manner. The only reasonable solution I have come up with is to allow the remailers themselves to choose routing, given that they have full knowledge of the current state of the froth.

Here we have the real head of the problem, as Hal so asutely points out: in your model, if the first remailer is bad, the message is compromised. If user encrypt to all remailers, they might as well encrypt directly to mole@snakeoil.nsa.gov. If they don't, they severly limit who can pick out their messages. In particular, they bypass transient remailers. But that isn't all. If the remailers pick the route, they are in a no better state than the users. Since the flushing attack requires remailers to operate on ticks, with carryover, an hour delay per remailer is almost minimal, untill traffic really picks up. So if some message routes through four remailers, a minimum of four hour delay results. In your case, this could easily move between in/out of service modes.

Think about the proposed extension to MixMaster to allow separate parts of a multi-part message to be routed separately, and consider whether you really want to have to do this by hand. I strongly suspect that most messages are currently routed via boilerplate scripts, which has to make the job of traffic analysis much easier for our good friend Eve.

Stupid is as stupid does.

By the way, a brief rant on a related topic; people speak of not trusting remailers any further than necessary, while I am clearly suggesting granting more authority and trust to the remailers. This notion of not assigning trust is simply nonsense. When you send a piece of mail to a remailer, encrypted or not, you are assigning complete trust in that remailer to keep you anonymous and not to forward your mail to the NSA immediately.

NOT TRUE. With proper use of encryption, you are trusting your first remailer only to not reveal that you sent a message, and not to correlate that message to the one it sends out. With rational use of garbage running two deep, you can even suffer this loss without significant harm.

This does lead to a related problem, however; if we allow remailers to pop up at random and join in the froth, how do we know that Deitweiller won't set up a number of black hole remailers that take your mail and throw it away, disrupting the froth, or forward it to nphard@nsa.gov?

How indeed? The reason we chain is because we _don't_ really trust our first remailer--or any other.

Fortunately, we already have the PGP web of trust model in place and can use it to good effect in this case. Remailers should simply not route mail through any remailer whose public key is not trusted unless explicitly ordered otherwise. This ring remailers to the user--with an exception list for those not "live".

Nathan