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

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 <martin@gwerder.net> 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),
> rfc-ise@rfc-editor.org
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>