Subject: [Secdispatch] A protocol for anonymity

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Sat, 9 Mar 2019 02:42:04 -0800

Hi,

Martin Gwerder has presented his draft to me for publication on the
Independent Stream.

https://datatracker.ietf.org/doc/draft-gwerder-messagevortexmain/

The document describes and specifies a protocol designed to achieve
anonymity by embedding messages within existing transfer protocols such as
SMTP or XMPP.

Martin tells me that he has made some overtures to the IETF, but has been
unable to find an opening to discuss his work. I think that may be because
it can sometimes be quite hard for a newcomer to work out how to find a
way in, especially for a topic that is not easily aligned with what we're
currently working on.

So, before I take this under my wing, I wondered whether you see a place
where you think this should be discussed within the IETF.

Thanks for any clues,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Hernâni Marques (p≡p project) <[email-masked]>
Date: Sat, 9 Mar 2019 13:42:42 +0100

Hello Martin

Thanks for this contribution: that sounds very interesting -- we already
had such ideas already in within pretty Easy privacy (pEp); by instance,
for PGP/MIME with the SMTP transport, which is one of the reasons why we
do header protection by encapsulation (cf.
https://tools.ietf.org/html/draft-luck-lamps-pep-header-protection-00) ;
not sure yet if your approach works on the same application level, but
discussions on such approaches should go forward.

From pEp side we would also be interested to contribute to actual
implementations in such directions.

Is there already any practical work? Cannot grasp that from the draft. :)

Greets

Hernani

PS:
I also added the MEDUP list CC, which exists to discuss concrete drafts
(ideally with Running Code) to achieve decentralized privacy forms:

https://www.ietf.org/mailman/listinfo/MEDUP

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 9 Mar 2019 12:54:13 +0000

> Martin Gwerder has presented his draft to me for publication on the

Seems like something that ought be relevant for the pearg. [1]

S.

[1] https://irtf.org/pearg

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Mar 2019 02:20:23 +0000

>    https://datatracker.ietf.org/doc/draft-gwerder-messagevortexmain/
  
I am VERY concerned about publishing something that claims to be a protocol for anonymity that has no security analysis and seems to be the work of one person.

---

From: Martin <[email-masked]>
Date: Mon, 11 Mar 2019 06:31:01 +0100

Hi Rich

Thanks for your concern. I understand where it is coming from. The
reason why Security Considerations are so small is that there is another
(academia) document dealing mainly with the security of the protocol.
Although the thesis has not been published (still needs lecturing, a
couple of attentive eyes questioning everything, and extension of some
sections), it is linked in the document, and you may read it. I felt
that including this into the RFC is too much by far. I, therefore,
referenced it in the first paragraph. Do you think that this was the
wrong decision?

You made definitely a valid point: Why believe a single person (in terms
of an administrator of a system or writer of a paper)? My reply is: You
should not. Read it and build your own opinion. There are a lot of minor
flaws in the protocol depending on how your adversary looks like. A lot
of "do's" and "donts's." If you are looking for the "why's" then reading
[MVAnalysis] is mandatory.

Another main problem is censorship resistance. The more you regulate the
behavior of the node, the easier it is to identify nodes (at least in
some points). I, therefore, tried to integrate all absolute mandatory
rules and to leave freedom to all other rules. I am sure willing to
change that decision if you think it should be entirely included in the
document instead of linking, but the document is already far from being
lightweight.

Regards
Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Mar 2019 14:31:37 +0000

I would turn this around: why does this have to be an RFC?

---

From: Martin <[email-masked]>
Date: Tue, 12 Mar 2019 07:18:51 +0100

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Mar 2019 15:41:13 +0900

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

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 12 Mar 2019 03:42:49 -0700

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

-- 
Adrian Farrel (ISE),
[email-masked]