1996-05-31 - Re: remailers, mail technology

Header Data

From: Bill Stewart <stewarts@ix.netcom.com>
To: cypherpunks@toad.com
Message Hash: f0dae1d52cd4f7edcbe99649e18945458de1e2aeb6511af6cdda1cfa0ae30051
Message ID: <199605310904.CAA05411@toad.com>
Reply To: N/A
UTC Datetime: 1996-05-31 14:26:47 UTC
Raw Date: Fri, 31 May 1996 22:26:47 +0800

Raw message

From: Bill Stewart <stewarts@ix.netcom.com>
Date: Fri, 31 May 1996 22:26:47 +0800
To: cypherpunks@toad.com
Subject: Re: remailers, mail technology
Message-ID: <199605310904.CAA05411@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


>>>Why would anyone set up a remailer at Lance's (or Sameer's) machine?
>>>They have remailers running already. If the thugs break root and obtain
>>>one remailer key from a machine, they probably get all the keys on that
>>>machine, compromising all the remailers in one single attack. Or am I
>>>missing something? Is there any benefit of multiple remailers on a machine
>>>where root is running his own remailer?

There are multiple threats that remailers have to face; multiple remailers
on one machine are jointly vulnerable to some of them, but separately
vulnerable to others.  If there are keys stored in plaintext on a machine,
then root-breakers can steal them (unless it's running a multi-level secure
operating system that can prevent that, if physical security is maintained.)
Thugs confiscating the hardware or trashing the OS obviously break all the
remailers at once, though that's only denial of service and not compromise.
Offline remailers using POP, UUCP, or other mail forwarding also don't risk
compromise (if they only accept encrypted messages), because they don't
keep keys or perform encryption on the ISP's server.  For all of these cases,
the remailer-positive ISP provides a certain amount of flak catching,
but can also avoid much of it because _he_ isn't running the remailer -
his customers are, and if the remailer gets abused, maybe they'll have
to become ex-customers.  That's especially effective for ISPs that support
customers with their own DNS names - foobar.com is owned by someone other than
Sameer, and if Sameer has to squash them, maybe they start getting hosted
by Lance instead, or by AOL, or by YAISP.SF.CA.US.

Telnet-only shell account providers probably get a little less deniability than
dial-only IP+POP providers or especially dial-only IP-only providers.
(On the other hand, the fact that Sameer's systems are telnet-only means
that users can be spread around to other dial-IP providers, including
all those 10-hour AOLers he just has to keep squashing :-), while if he
had dial-up users the thugs might go for telephone records.

====

What kind of technical infrastructure would help run remailers in environments
like this?  I can think of three things
- Encrypted IP sessions (either IPv6, if it ever gets deployed, or swIPe)
- Encrypted POP and SMTP client/server interactions. 
- User-based encrypted communications (SSH? SSL?) relaying POP/SMTP.
If we're going to get convenient wide deployment before the millenium brings
IPv6,
the approach will either need to run on shell(-like) accounts only,
or else will need to piggyback on SSL.  Either way, rather than get everyone
to replace POP3 with CryptoPOP (they haven't even done IMAP), it'll probably
take some kind of relay that sits on your desktop machine, speaking
POP3-server on one side and CryptoPOP on the other.  And you'd have to
handle firewalls.

Is there any way to get Netscape to implement something like pop3: and smtp:
services for the client software (or do them as plug-ins)?  Adding them to
a server (i.e.. Apache-SSL) would allow SSL to do the crypto, and would
mean you could use https: proxies to handle firewalls, since everybody's
got to deal with them anyway.
#					Thanks;  Bill
# Bill Stewart, stewarts@ix.netcom.com, +1-415-442-2215
# goodtimes signature virus innoculation







Thread