Re: Frothing remailers - an immodest proposal
-----BEGIN PGP SIGNED MESSAGE----- - -----BEGIN PGP SIGNED MESSAGE----- In article <9501312152.AA10208@toad.com>, <kevin@elvis.wicat.com> wrote:
It seems to me that the current remailer web suffers a fundamental flaw. It is simply too static.
Agreed, of course. I also don't really want to quote your entire article but want to throw some points into the discussion. In general, I think you've got a good approach but might be a little too tied to instant-gratification use of IP. I touched on some of this a while ago, in the thread "Broadcast and the rendezvous problem," and have thought about it a bit more after getting others' comments: 1. Broadcasting every couple of minutes isn't necessary and is undesirable due to the real limitations of the Internet. A remailer could broadcast its location with a time-out on the location without a constant stream of availability announcements. In your position for example, you'd broadcast a message at 5 pm with a 16 hour valid time. 2. This is actually unnecessary for your situation: All you need to do is advertise your location as a "real" remailer and then have a cron job that kill sendmail at 5pm on your remailer machine (assuming you have a spare machine that doesn't need to run sendmail). The mail network is flexible enough that things will Just Work. Mail won't go through instantly during the day, of course, but that just helps to muddy up the mix. 3. Broadcasting over live IP isn't all that great a model. Ideally, you'll use a mechanism that doesn't require instant communication among hosts. I favor USENET for this: messages have a naturally long life- time and the network is self-adjusting. If a direct route is temporarily unavailable, an indirect one will often manifest itself. I also favor using USENET store-and-forward for the messages themselves for the same reasons: traffic analysis is impossible inside the web and direct routes are not necessary. 4. Using a PGP-style web-of-trust is important. In the ideal situation, one human in an extended web can certify individual remailers and all other remailers close enough on the same web of trust would pick up the message immediately. Just some thoughts, - - -- Todd Masco | "life without caution/ the only worth living / love for a man/ cactus@hks.net | love for a woman/ love for the facts/ protectless" - A Rich Cactus' Homepage - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLy6+ThNhgovrPB7dAQHoDQP/UDn2GV7Jq8C3nQyN9IhvGMUTGnBjcL+k zCPgTOLjANMrMN791VdeoNs9rR3QKFdFR9y0p39lka0p+9n1I3hDuEKyAX8Cicub h0/eyr54bEzC6Q2L06VlIzDac9K7kILUkIf2ypgeXTrFuMSZITy+z0ugDeq3NA7B W+gkl82hJZk= =69b2 - -----END PGP SIGNATURE----- - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLy73lyoZzwIn1bdtAQG/8wGA1kS3RyqBsxOZgniuxZqGySeybSJQuVp4 3zsxH545MqhBXmh16Gh4LvBlkre+9JYT =Evbh -----END PGP SIGNATURE-----
In article <9501312152.AA10208@toad.com>, <kevin@elvis.wicat.com> wrote:
It seems to me that the current remailer web suffers a fundamental flaw. It is simply too static.
It is worthwhile remembering that a remailer network has two characteristics of service: the fact of delivery, and silence in the internal facts of that delivery. That is, you want your email to get there, but you don't want anybody else to know how it got there. There are correspondingly two trusts in the function of a remailer, namely, a trust in reliability, and a trust in silence. It is very important to remember that only one of these is externally verifiable. Your mail gets to its final location; you can tell that. What you can't tell (external to the remailer) is whether the remailer kept a copy of the mapping between input and output messages. Now, dynamic rerouting is good for better delivery, but is bad for the trust in silence. Trust in externally unverifiable properties is _not_ transferrable. Just because I believe that my regular remailer is OK does not mean you do. The creation of these links of trust is not something that can be automated solely by the remailer operators. The end users of the remailers are the endpoints of this trust relationship. The end users must be involved, either directly or through some (legal) agent, in the manipulation of these relationships. Any solution which tries to do this independent of the end user is broken, by definition. Eric
participants (2)
-
cactus@seabsd.hks.net -
eric@remailer.net