Subject: [Endymail] Onion Routing over SMTP.. impossible by design?

From: carlo von lynX <[email-masked]>
Date: Sun, 5 Oct 2014 17:57:54 +0200

Hello everyone, I was pointed here by Hannes and Stephen -
some may remember me from IMPP, STRINT or recently IPEN.

	As a side note please acknowledge the updated version 
	of http://youbroketheinternet.org/secure-email with
	more reasonable information concerning Key Management 
	and a more accurate list of post-SMTP mailing systems,
	in particular the ones using the Public-Key Routing 
	paradigm (Re: What are the problems?).

What I specifically want to talk about in this thread
is the "Onion Packaging?" in Dave's slides (number 9):
http://www.ietf.org/proceedings/90/slides/slides-90-saag-2.pdf

Onion routing works by letting the sender pack up the crypto
layers for each inbetween node up to the final recipient. If
SMTP were to allow that, it would re-introduce relaying which
used to be its favorite backdoor for SPAM.

The only way for an MDA to receive a message from somewhere,
decrypt it, then find out it needs to forward it to another MDA,
would be to have a large view of the social graph of users and
.. erm.. servers.. in order to know that if the message came
from eris it is probably safe to forward on to tolsun.

To me this sounds like a catastrophe waiting to happen since
SMTP by default has no trust architecture, thus any onion
routing would open up large windows of opportunity for spammers
since once the SPAM has arrived at destination, the recipient
can no longer figure out where it originated from - thus there
is no way of protecting yourself.

All Tor-and PK-routing based systems have solved this by requiring
pubsub relationships, thus making SPAM at worst annoying, but
ineffective at its primary intent.

If I'm not mistaken, it is impossible to implement metadata
protection on top of SMTP while also maintaining compatibility
to its subscription-free transmission model.

Any mistakes in my reasoning?

Best from Berlin,
    CvL

-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet

---

From: Tom Ritter <[email-masked]>
Date: Sun, 5 Oct 2014 12:50:40 -0500

> used to be its favorite backdoor for SPAM.

Indeed, when Onion Routing (well, Mix Networks, similar but different)
were built for SMTP, they were used for spam and abuse. As well as
legitimate traffic of course.

> from eris it is probably safe to forward on to tolsun.

You need a directory of servers, yes.  Users, no.

> is no way of protecting yourself.

Spam detection does not _have_ to rely on originating source, although
obviously that's a large input to a spam detection system.  The
popularity of the system also affects it's spam rate.  In the
existing, small, unpopular SMTP-onion-routing systems deployed today
(again, technically mix networks), I receive a very high degree of
signal-to-noise-ratio of messages, because they are not in popular
use.

> ineffective at its primary intent.

I'm not clear what you mean here.  In my mind, Tor is not set up as a
publisher-subscriber relationship at all, but perhaps you mean
something different.

> Any mistakes in my reasoning?

I feel like you've made an assertion: "it is impossible to implement
metadata protection on top of SMTP..." but not supported it very
strongly.  One, you talk only of Onion Routing - but that is merely
one mechanism of metadata protection.  There is also Broadcast
Transmission, Mix Networks, and other more complicated systems like
PIR.  Two: It is impossible to prove a negative, that something must
not exist or not be possible.  I think there are a multitude of
systems that have been designed or could be designed that would feed
into this debate.  If you want to make an assertion that something is
impossible, I would expect a more descriptive exploration of the
problem space, and attempting to address several potential ideas and
why they do not work.

For example: Mix Networks for SMTP (remailers) have existed since the
late 90s, with one network still deployed and being developed (slowly)
- Mixmaster. A second more sophisticated one was also built and
deployed (Mixminion).  nymservs, allowing anonymous email recipient
(instead of delivery) have also evolved over the years, with several
deployments, versions, and academic papers written about them (like
Pynchon Gate).  And shared mailboxes (alt.anonymous.messages) is a
reasonably well workable system for certain types of communication,
absent easy-to-use tooling for it that leads to various security
failures.  Finally, systems like Persona and Pond provide metadata
protection in related situations that may inform a new evolution of
email, existing side-by-side traditional SMTP.

I think it's entirely reasonable to say "I don't see a way this would
work" - indeed there are some hard problems in the space, followed by
the additional problems of developing robust codebases and large-scale
deployment.  But there are multitude of architectures out there and
I'm hopeful that by learning and borrowing from each, we can find a
system that provides the protections people want to achieve,
indistinguishable as possible, allocating the burden appropriately.

-tom

---

From: carlo von lynX <[email-masked]>
Date: Sun, 5 Oct 2014 22:01:13 +0200

> obviously that's a large input to a spam detection system.  The

Indeed, considering that future SPAM would be encrypted to the end
recipient, so spam assassination has to happen on the end system.
Defeats models that detect SPAM by the way it looks similar while
being delivered to a multitude of recipients.

> publisher-subscriber relationship at all, but perhaps you mean

Pond, the mail system you mentioned, uses Tor hidden services and requires
a subscription/authentication exchange before being able to mail.

> metadata protection on top of SMTP..." but not supported it very

I started a discussion posing that question.. could it be it isn't
actually feasible..? Indeed from a scientific point of view quite
unlikely to be a provable statement.

> Transmission, Mix Networks, and other more complicated systems like

I specifically asked about onion routing since I wish Bitmessage
good luck in finding a way to segment the broadcast space but I
doubt that approach to be viable over the existing SMTP system.

Mix networks have the disadvantage of requiring trust from their
users, correct? In a world where computing centers can receive a
knock on the door and servers be systematically, especially virtual
ones, tapped with memory scanning for private keys... I did not
intend to speak about that model.

I am thinking of an SMTP-based onion routing system where the SMTP
hosts act like relay nodes and the MUA creates the message encrypted
to all in-between relay hops. The optimization suggested by the
authors of PIR-Tor is applicable, but doesn't affect the challenge
of getting it to work with the existing SMTP federation.

I'm not saying that mixing and broadcast is scientifically absurd,
but sufficiently uninteresting within my personal judgement, so
I am asking specifically what I find interesting.

> not exist or not be possible.  I think there are a multitude of

Luckily I'm not trying to prove it, just gathering some good thinking
on the topic.

> problem space, and attempting to address several potential ideas and

That's why I am glad you gave such an exhaustive reply.
Let's dig deeper into the problem space.

> work" - indeed there are some hard problems in the space, followed by

Sure, if we include post-SMTP systems I know that solutions are feasible
but I was very specifically wondering if the backwards compatibility
with SMTP's presumption that you can mail anyone anytime breaks the scheme
of onion routing approaches.

Thinking it through it seems to me a bit like a time bomb. You can start 
using a new mailbox with a new public key and share these with your
contacts - but the moment any of your contacts gets her device p0wned by
a secret service or other malware deployer, your mailbox can be DoSsed
with epic amounts of SPAM and only the end node would have a vague chance
of distinguishing signal from noise.

Sure, this isn't a very scientific assertion, but to me it sounds like
doing Onion Routing on top of a network of SMTP servers is a very bad
idea.