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