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

carlo von lynX <lynX@i.know.you.are.psyced.org> Sun, 05 October 2014 15:57 UTC

Return-Path: <lynx@lo.psyced.org>
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 8488D1A0033 for <endymail@ietfa.amsl.com>; Sun, 5 Oct 2014 08:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.787
X-Spam-Level:
X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham
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 XTc64vA-uw9Y for <endymail@ietfa.amsl.com>; Sun, 5 Oct 2014 08:57:48 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D58E1A002D for <endymail@ietf.org>; Sun, 5 Oct 2014 08:57:48 -0700 (PDT)
Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s95FvtUb027974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <endymail@ietf.org>; Sun, 5 Oct 2014 17:57:55 +0200
Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id s95FvsUE027973 for endymail@ietf.org; Sun, 5 Oct 2014 17:57:54 +0200
Date: Sun, 05 Oct 2014 17:57:54 +0200
From: carlo von lynX <lynX@i.know.you.are.psyced.org>
To: endymail@ietf.org
Message-ID: <20141005155754.GA27470@lo.psyced.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/YbEP-16ZSWaki4ieVAwk2_1IiFs
Subject: [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 15:57:50 -0000

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