On return addresses

[hughes@ah.com (Eric Hughes)]

I've been troubled for many months by an invariant in all forms of
return address schemes: The outside world contains sufficient
_persistent_ information to find a real adress.  There are lots of
clever schemes to split this information up so as to require
reassembly between many parties, but the information is still out of
one's control.  (I use 'reassembly' rather than 'collusion' since the
latter indicates an intent; see my rant of a few days ago.)  The
fundamental problem seems impenetrable.

So how do we solve it?  By abandoning return addresses and using mail
spool facilities.

Consider the following service.  

1. I have a machine and I'll sell you an address on it, say
"onyma@privacy.net".  This address is _not_ an account, merely an
address.  Your mail is password or public key protected.

2. When mail come in for you, it sits in a spool.  This service comes
with a spool of a certain size and an allowance for checking your mail
at a certain rate, with overages at extra cost for both.  (This is to
bound known promised capacity of the machine by a sufficient amount of
money to pay for it.)

3. Your mail sits in the spool until you access it with, say, a POP
client like Eudora.  Just point the client at a different address to
pick up mail.  The server can further support a number of protocols
for getting the mail, including a mail server command of "send me a
mailbox file of my waiting mail".

The main advantage is that the only _persistent_ information out in
the world is the address itself and the authenticator (password or
public key).  The address is already public and the authenticator is
arbitrary, so no identity information is persistent.  

A complete chain could still be forged between sender and receiving
pseudonym, but we now have some amount of forward secrecy.  If in fact
an intermediate link does discard connection information, it is gone
forever.  With any kind of SASE, however, the information therein,
however encrypted, still contains a full path back.

Now consider two ways of getting your mail out of this service,
supposing you don't trust the service with your identity.

A IP redirector can be with POP service to conceal origin from the
mail service.  An IP redirector is a remailer for packets, with a
bidirectional link set up when the service starts and removed when it
goes away.  Matt Blaze has a name for this--'packet laundry'--which is
a wonderful but politically unfortunate term.  The IP redirectors can
be chained just like remailers.

With a mail server, the command to 'send me my mailbox' can be sent to
a remailer address with an encrypted remailing block prepended.  In
this case, however, the encrypted remailer block is provided with the
mail command that requests the mailbox and it is not by design stored
persistently.  (By design.  It could, of course, actually be stored.)
The address on the other side of the first remailer hop could be
another mail spooing service, in addition.

The elimination of persistent identifying information for return paths
is a worthwhile design objective.  I propose that we start thinking
about it more thoroughly.

Eric