Re: What about making re-mailers automatically chain?

[Greg Broiles <gbroiles@netbox.com>]

>Would it be a good idea to have a re-mailer "randomly" decide whether to
>send the mail to the destination or to another re-mailer.

No. The remailer user should be presumed to know what s/he wants. Some
remailer users may want to optimize for speed and certainty of delivery and
therefore use a short chain; other users may want to optimize for more
difficult traceability, and consequently choose a long chain. Remailers
shouldn't try to rewrite the user's (perhaps) deliberate balancing of these
factors.

Also, users may choose to use or not use certain remailers based upon their
policies, the reputation of the operators, the legal rules affecting the
operators, and so forth. These choices should also be left to the user and
not overridden by third parties. 

> If all
>re-mailers performed this way, not even the sender would know the path.

I don't see why this is useful. As things work now, only the sender knows
the path, assuming chaining and nesting encryption. How does taking away
the sender's knowledge add security?
 
Adding hops to the chain requires that remailers keep track of other
remailers; a robust way of doing this would require that they also keep
track of reliability, because deciding to add a downed (or unreliable)
remailer to a chain would be harmful. To prevent an active and hostile
eavesdropper from adding itself as a remailer eligible to receive extra
hops (and then dropping or logging the traffic), this remailer status
information should be provided by a trusted source in a secure manner.

All of this (adding remailer status tracking based on frequent updates of
digitally signed information from a trusted third party) can be done, but
it's a pain in the ass to code, and it doesn't add anything that users
can't get for themselves. (Users who want long difficult-to-trace chains
can already generate them. They can also let software generate random
chains at the source.) It also may degrade performance for users who value
speed and reliability over untraceability.

So I suggest that it's not very useful. The best way to implement this
would be to modify remailers to use "Anon-To: random" or "Random-To:
xxx@yyy.zzz" header commands, such that users who desired the random hop
behavior could get it, but users who didn't want it wouldn't get it
unexpectedly. (Isn't some remailer doing this already? I've lost track.) 

--
Greg Broiles                |  "We pretend to be their friends,
gbroiles@netbox.com         |   but they fuck with our heads."
http://www.io.com/~gbroiles |
                            |