From: cactus@seabsd.hks.net (Todd Masco)
Date: Tue, 31 Jan 95 18:57:30 PST
To: cypherpunks@toad.com
Subject: Re: Frothing remailers - an immodest proposal
Message-ID: <199502010253.VAA03904@bb.hks.net>
MIME-Version: 1.0
Content-Type: text/plain


-----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-----