Anonymous Transport Agents (Was: Latency vs. Reordering)

hughes@ah.com (Eric Hughes) writes:

> Simulating any of the salient features of a link encryptor over the
> Internet is an interesting exercise, particularly in regard to price
> negotiation with your service provider.

     I'm about to branch into the limits of my knowledge on this
particular topic: I run a DOS site under a heavily modified version of
Waffle (1.65 base), so the Unix-ish transport mechanisms are a tad out of
my realm of knowledge. With that in mind...

     Suppose an encryption-savvy mail transport agent, say ESMTP, was
developed. Further suppose that part of handshaking protocol for this
transport protocol included an ENCRYPTED reverse lookup on IP identities
to check that the message is actually coming from where it claims it's
coming from.  Suppose again that the results of this lookup were only
checked for correctness (boolean), and then discarded WITHOUT LOGGING, or
at least with minimal logging. If the reverse lookup was TRUE (IE: the
sending machine was who it said it was), the message was accepted. If it
failed, the message would be accepted, and then sent to the bit bucket.

     In this model, one could provide anonymous transportation of
anonymous mail FOR EVERY MACHINE ON INTERNET providing that the original
message wasn't forged. All that would be required (beyond running ESMTP)
is an encrypted version of the return address (a la Soda remailer) to be
placed some predetermined place in the message.

     This seems too easy: What am I missing? Have I actually come up with
a way to do this?

                                             --Jeff
--
======  ======    +----------------jgostin@eternal.pha.pa.us----------------+
  ==    ==        | The new, improved, environmentally safe, bigger, better,|
  ==    ==  -=    | faster, hypo-allergenic, AND politically correct .sig.  |
====    ======    | Now with a new fresh lemon scent!                       |
PGP Key Available +---------------------------------------------------------+

Jeff Gostin <jgostin@eternal.pha.pa.us> writes:

>     Suppose an encryption-savvy mail transport agent, say ESMTP, was
>developed. Further suppose that part of handshaking protocol for this
>transport protocol included an ENCRYPTED reverse lookup on IP identities
>to check that the message is actually coming from where it claims it's
>coming from.  Suppose again that the results of this lookup were only
>checked for correctness (boolean), and then discarded WITHOUT LOGGING, or
>at least with minimal logging. If the reverse lookup was TRUE (IE: the
>sending machine was who it said it was), the message was accepted. If it
>failed, the message would be accepted, and then sent to the bit bucket.

I can see two problems.  First, at least the first machine on the trans-
port path will see both your origin address and your destination address.
So it is in a perfect position to do traffic analysis.  Many users may
not have the ability to control which machine this is since routing is
usually automatic these days.

Second, if each machine simply saves a message and sends it on, then even
if the messages are encrypted there will probably be timing relationships
between the incoming and outgoing messages which will allow them to be
linked.  So someone monitoring the intersite communication channels may be
able to track a message through the network just by noticing when it comes
into and goes out of each node.  This is why Chaum introduces message
batching and mixing at each node.

Hal