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

Tom Ritter <tom@ritter.vg> Sun, 05 October 2014 17:51 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7D41A0406 for <endymail@ietfa.amsl.com>; Sun, 5 Oct 2014 10:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcgz0kzCsT-u for <endymail@ietfa.amsl.com>; Sun, 5 Oct 2014 10:51:01 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB911A03D0 for <endymail@ietf.org>; Sun, 5 Oct 2014 10:51:01 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id x19so2138873ier.6 for <endymail@ietf.org>; Sun, 05 Oct 2014 10:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aJQld9uBHGo4u6TwlmGz/tTgfmOGiTFqptNlENJ+S0w=; b=VnOOOaPdINPYWfza5r+6e4eZQa0u8jdjTCCvH3BtOJ/olbg/NhNJAGKVm3WTUhwGc/ 1MsRtcRd700bxOTbAeunOEdT3v8p4xWIzCie85Fr9HENVH3uI/m27VL59aWiK1jWHjns 64mDKUexGIA/BGPUAJq0Y+GfcaO42c1WvJeow=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aJQld9uBHGo4u6TwlmGz/tTgfmOGiTFqptNlENJ+S0w=; b=dpi2RP+stXTxnB0HaRuByJbqYwcRV2DaNZNWkMAH2Y70UH8efyvVLOQHoWAnj6infL u/zcf79MNKGmPXDRWvbhu5BYqeDXsZyZeoNj0YEbgZe5i4lNivSSZDPPj5o0uucXeh/k ppfM5raZPBT6fDzcqyCQpUNIJMEf6Wb31uAc4hKA5y34ELBtIlAjm2A6vOuix7lL0x5W c1qs8uTVAmuJQPWj5/BUnmgm20dmRbVcN2NITpmof+sVawm/ncXTk4JRgPL6505dQSix BIec2aUX4w2KB+JJj2iputd23kVCn+bYaFyMhZ++1iBpRjoUiXg5qOW51nJZIy6paSRz 4fGw==
X-Gm-Message-State: ALoCoQndv2FVaZplqJzpHJbP2cmHK8E8e6Pqnw81zHUFwZoccpxWP8pZXgryGPEQHENbD8uvJ/RK
X-Received: by 10.50.73.163 with SMTP id m3mr14921471igv.28.1412531461046; Sun, 05 Oct 2014 10:51:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.17.15 with HTTP; Sun, 5 Oct 2014 10:50:40 -0700 (PDT)
In-Reply-To: <20141005155754.GA27470@lo.psyced.org>
References: <20141005155754.GA27470@lo.psyced.org>
From: Tom Ritter <tom@ritter.vg>
Date: Sun, 05 Oct 2014 12:50:40 -0500
Message-ID: <CA+cU71=Ab+Yyp=BuBk73P66dHT6Pqk4TPhUW3+hjbe03Vz7EQA@mail.gmail.com>
To: carlo von lynX <lynX@i.know.you.are.psyced.org>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/fynAuf_dNo8zkTvoog8DRgSAlfo
Cc: endymail@ietf.org
Subject: Re: [Endymail] Onion Routing over SMTP.. impossible by design?
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Oct 2014 17:51:03 -0000

On 5 October 2014 10:57, carlo von lynX <lynX@i.know.you.are.psyced.org> wrote:
> 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.

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.

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

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

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

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.


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

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.


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

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