Re: [xmpp] End-to-End Encryption Milestone

[Dave Cridland <[e-mail]>]

On Tue, Feb 25, 2014 at 12:11 PM, Tobias Markmann
<[e-mail]>wrote:

> I think what's really needed is some kind of overview/comparison document
> about that current status. While the current requirements document is a
> start in listing some potential requirements, modern IM use cases are a bit
> more complex, w.r.t. multi-device and the mobile application scenarios.
>
> So basically a document that compares existing proposals, like OTR, PGP,
> XTLS and maybe even some more general e2e IM security solutions like the
> TextSecure protocol or multi-party OTR, and analyze those regarding their
> security, support for PubSub/MUC, support for offline messages, support for
> multi-device usage, and possibly even more.
>
>
That sounds really useful. I suspect that:

a) Even quite experienced XMPP developers probably don't know what's on
offer, and what they provide.

b) It'd help focus discussion enormously, by enumerating the requirements
properly.


> On Tue, Feb 25, 2014 at 12:23 PM, Dave Cridland <[e-mail]> wrote:
>
>> Doing it within the XSF would *possibly* be simpler in terms of process.
>
>
> Indeed. I don't know if the IETF is the right place for a status quo
> comparison document or if it'd be more attractive within the XSF with less
> process. I for one would gladly review and try to contribute as much as
> possible to such document. Reviewing current proposals and exposing their
> advantages and shortcomings, especially regarding multi-resource and
> offline usage, would be a great way to start looking for possible solutions
> for XMPP.
>
>
A comparison document such as you're suggesting could probably be done as
either; the process overhead isn't important either way. I suspect that
longer term, it'd be nice to maintain it (unless we think we'll find the
Final and Ultimate Solution to Encryption (FUSE), in which case it'll be
only useful as a snapshot.

If we want a "living document", then the XSF affords us that relatively
easily, whereas if we did it as an I-D, I wouldn't press for publication as
an RFC at all. In that sense, it'll be lower process within the IETF.

Dave.