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

[Barry Leiba <[e-mail]>]

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 <[e-mail]> 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?
> >