Re: [dispatch] [Secdispatch] A protocol for anonymity

"RFC ISE (Adrian Farrel)" <> Tue, 12 March 2019 10:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CA4812E036; Tue, 12 Mar 2019 03:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rUVMMiW6bjjF; Tue, 12 Mar 2019 03:42:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 72C89129A85; Tue, 12 Mar 2019 03:42:56 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB9931C3F62; Tue, 12 Mar 2019 03:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4zwglBV-4VP8; Tue, 12 Mar 2019 03:42:49 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 441AB1C3F4D; Tue, 12 Mar 2019 03:42:49 -0700 (PDT)
Received: from (SquirrelMail authenticated user rfcpise) by with HTTP; Tue, 12 Mar 2019 03:42:49 -0700
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 12 Mar 2019 03:42:49 -0700
From: "RFC ISE (Adrian Farrel)" <>
To: "Barry Leiba" <>
Cc: "Martin" <>, "Salz, Rich" <>, "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <>
Subject: Re: [dispatch] [Secdispatch] A protocol for anonymity
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Mar 2019 10:42:58 -0000

Thanks Barry,

Useful comments.

To be clear on the ISE position, here...

If there is a home for this work in the IETF (or possibly the IRTF), I
would be delighted to see the work moved there, discussed, updated, and
published with IETF consensus. That is, in fact, the purpose of this

Although it may be late for a presentation in Prague, I believe that the
corridors in the Hilton will be fully functional, and that the mailing
lists run 24x7 so we should at least be able to get an idea of whether
there is support to look at this in the IETF. (I am getting a strong hint
that that is the case, but as yet no firm commitment from a WG chair that
their mailing list is the place to focus the conversation.)


Barry Leiba wrote:
> I would feel better about this if it were done as an Experimental RFC
> in the IETF stream, ideally through an ART/SEC working group, as it's
> too much to be AD-sponsored.  As such, it should go through
> secdispatch or dispatch, and it's a bit late to do that for Prague.
> I'd be hesitant to actually *block* it from the Independent stream
> (more specifically, asking the ISE not to publish it because it needs
> IETF review), but I'd rather see it in the IETF stream.  I also don't
> know the history here, as I'm just stepping in as AD now, so perhaps
> the issue of doing it in the IETF stream has already been hashed out.
> If so, please clue me in.
> Barry
> On Tue, Mar 12, 2019 at 3:19 PM Martin <> wrote:
>> Hi Rich
>> This is a valid point. Requested status is experimental. This allows
>> going for a standard later. So the primary goal is to become a standard
>> on the long term and to expose the protocol to a broader public. In my
>> eyes, for the standard, it would require that we have two seconding
>> documents — one dealing with best current practices and one focusing
>> security considerations (maybe both in one document). The main problem
>> with those two documents is not the protocol itself. As SMTP or HTTP in
>> its pure form, this is a transport protocol only. It does not deal with
>> the client side or the content itself.
>> Anonymity is broken easily by the users themselves. As an example, you
>> may take the fact that almost no user is ready to write emails in plain
>> text. They want to embed graphics and emoticons. Allowing HTML encoding
>> on the other side makes the protocol vulnerable to bugging attacks. At
>> the moment I am using Thunderbird as the client and the MessageVortex
>> node as "local mail server." While this makes sense from the user
>> perspective (no new client), it is maybe not the wisest decision from an
>> anonymity perspective. This, however, is not a problem of the protocol.
>> MessageVortex allows transferring any message and is not limited to
>> emails. These possibilities should be further explored.
>> At least for my person, this protocol opens a whole new world full of
>> possibilities. So I am very keen to see what it can do.
>> Regards
>> Martin
>> Am 11.03.2019 um 15:31 schrieb Salz, Rich:
>> > I would turn this around: why does this have to be an RFC?
>> >

Adrian Farrel (ISE),