Frothing remailers - an immodest proposal

[Nathan Zook <nzook@bga.com>]

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 requires remailer operators to
>cooperate to some extent to validate one another's remailer keys, but
>does confer the great advantage of portable remailers as mentioned
>above; if I run a trusted remailer on one machine, I can move it to
>another machine, and as soon as I advertise the new address and the PGP
>public key, it is a trusted and useful part of the froth.
 
Actually, there may be something here.  I don't know about you all, but my
PGP isn't very happy about all these new remailer keys.  We could agree to
the following standard:  Signing a remailers' key means that you believe
the remailer to be secure.  Trusting a remailer key means trusting the
remailer operator to validate other remailer's security.  This adds a whole
new meaning to the phrase, "key compromise certificate".
 
 
>While we are advertising a PGP key and internet address, we might as
>well incorporate other useful information. For instance, remailers could
>advertise their maximum latency. 
 
While I agree that it is useful to post the operating characteristics of
the remailers, the maximum latency must theoretically be infinite in the
standard model to prevent flushing attacks.
 
>    Kevin
 
 
 
Hal <hfinney@shell.portal.com>:
 
 
>I do like Kevin's ideas about a dynamic remailer net, but I think
>another approach would put more smarts into the client program used by
>the originator.  
 
Hear ye, hear ye!  And along those lines...
 
I'm scetchy (at best) by what is meant by "pinging" a remailer.  Would it
not be possible for live-on-the-net remailers to accept a (socket?) quick
check to see if they are online?  If so, then the ping would only work if
the remailer was active when tried.  Furthermore, client software could
startup by sending out these pings, and presenting only responding
remailers to the user--with an exception list for those not "live".
 
Nathan

P.S.:  Late breaking weakness:
Pinging a group of remailers is strong evidence that you are about to 
send a message.