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

"Martin Thomson" <> Thu, 14 March 2019 03:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC029131264 for <>; Wed, 13 Mar 2019 20:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=dPSdl+zt; dkim=pass (2048-bit key) header.b=RM/frydD
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hd2q1fkBk2rR for <>; Wed, 13 Mar 2019 20:07:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7D6013125A for <>; Wed, 13 Mar 2019 20:07:00 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 245FB235F8 for <>; Wed, 13 Mar 2019 23:07:00 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Wed, 13 Mar 2019 23:07:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=message-id:in-reply-to:references:date:from:to:subject :content-type:content-transfer-encoding; s=fm1; bh=EYN7NjJoQ/zLt CIIy2eQz397tG8gWfLmkXQd3PxEfd4=; b=dPSdl+ztd8IeE2MBeMWIuN8LOyRsN qbggm9mz4gq1OboUM29FjAEBHP4ptyWdUiAdKY16LcY4ccX7ZSRieDuIB6g2ZELm c+ayfXtdcPp+5XyI2vNC1dLs4uPdWYiu/pSBjweq9Iwy6Fngo08qSutC76mW6tzV 1TE7yjHUqVph3Un/6doZGgo5+wZfCw7Glu6Wl25HWvIhop9EkIGCMJILnj2hwKGP ffdN9/c3YfelRGwooL3MF8njzZkxO2ilA/LxZJv4sh9oIiY9gFIvl1hQylhYQxAq Zix24aoGrpO2ONHHeaef2fYVG6N0ZvbmbCFPpO/VBOIdMhlVDByB/p25w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=EYN7NjJoQ/zLtCIIy2eQz397tG8gWfLmkXQd3PxEfd4=; b=RM/frydD ouaWEWctYDgkwqouIGH9wJ83xkct2k+VKf0CguvOuqxz/TF7BB2fyijRpKcIIULC 11XhLUjAGNjmM4xfoceo8R8GnQJm5U9ME60vVl0PyEIMPhGsNU1csE3r6hcfFckA 8A9SpFpnI+z7iZAupfg7Q7qau3ZMaiUfdwMPtmMGaflrANKuJo8G6uNHhMt+LmGc bbdCVXAr5DY4JpoXgBYIwqv2Cm+EW+G7jfKD8CBJvFSoJCLG2dR+nRKFabj8i17s zGVb+SzlHfw5lrEkdG1HjoJj+X+uAjJOBOGLOXfMemeEMey7Q9QxD0KHWPhNX6Ou DXR1XFwImOCEYg==
X-ME-Sender: <xms:U8WJXEQRAjRVvzK8yEXgZ8RD44rCef7-2COHAd-Uka-SO1JFHTjvng>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrhedugdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfgjfhffhffvufgtgfesthhqre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehhthhtphhinhhithhsphhurhgvfh horhhmthhhihhsihhsrghtrhgrnhhsphhorhhtphhrohhtohgtohhlohhnlhihrdhithdp ihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrh hophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:U8WJXLHhAcfXyVh49tCl5mtQOdyDPukDONlRWBcglfqASoOW0k8knA> <xmx:U8WJXJHtM2DfmbHTEUZXiilpH_J1kNWaG22f1HEs3ixJ67SZIXZsBQ> <xmx:U8WJXJSLaOy0iqHqUOn3MLd0ouTMvwQrBqe0tytk0NkAZLg-I4Cz3Q> <xmx:VMWJXFbCefOqR7wxEjduWBvktBHOGLqAoVA3AHbO0fwVCmM3EtNcsA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A33E7C32E; Wed, 13 Mar 2019 23:06:59 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5
X-Me-Personality: 92534000
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 13 Mar 2019 23:06:59 -0400
From: "Martin Thomson" <>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Thu, 14 Mar 2019 03:07:04 -0000

The challenging thing with a proposal that is as broad as this is finding a home.  There are, to varying degrees, lots of different pieces to this design.  Without going into the design in more detail, I see both cryptographic and transport elements.  Both of which are similar in the abstract to existing work in the IETF, but entirely dissimilar in form.  A dispatch group is likely the best target for this, but even then it is likely to contain elements for multiple areas (there's a whole section on routing that I think is probably not routing in the sense that it would fit in RTG, but it's still an entirely separate part of the design; there is also a section on accounting that might or might not be suitable for OPS).

That alone isn't information you could use to decide anything here (other than perhaps the shortcomings of the IETF when it comes to dealing with cross-area stuff).

I have some reservations about the lack of context in the proposal.  For instance, the section on accounting launches into mechanisms without establishing what is being accounted for and to whom.  A protocol like this would also typically require considerable security analysis.

This looks like a specification at the sort of level that would be appropriate for a BoF or dispatch session.  If there was significant interest in this, then I would expect to see - over time - those details filled in.  Using the dispatch process is probably right, and either would be fine.

On Tue, Mar 12, 2019, at 21:43, RFC ISE (Adrian Farrel) wrote:
> 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
> thread.
> 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.)
> Thanks,
> Adrian
> 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),
> _______________________________________________
> dispatch mailing list