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

["RFC ISE (Adrian Farrel)" <[e-mail]>]

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 <[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?
>> >
>
>


-- 
Adrian Farrel (ISE),
[e-mail]