[Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals

Dave Cridland dave at cridland.net
Mon Jan 9 10:24:04 UTC 2017

On 6 January 2017 at 08:36, Jaussoin Timothée <edhelas at movim.eu> wrote:
> Hi,
> I'm currently in the process of implementing end-to-end encryption in my
> project. I naturally had a look at the freshly published XEP-0384: OMEMO
> Encryption and I have some feedbacks to give on it.
> 1. Usage of Olm
> After some talks with members of the community it seems that this protocol
> was selected for two reasons : it was quite well documented (for the crypto
> part) and didn't have legal concerns.
> I was quite disappointed by the library provided by Matrix for this protocol
> (https://matrix.org/git/olm/about/). The Javascript version of it needs to
> be generated from the C/C++ code using a tool called emscripten
> (https://kripken.github.io/emscripten-site/index.html) that is actually not
> packaged on Debian (only a very old version from 2014 is available for sid)
> and seems to rely on a forked version of LLVM.
> Also I couldn't find any clear/simple documentation that could help me with
> the integration of the library in a project (like we can have for libsignal
> here https://github.com/WhisperSystems/libsignal-protocol-javascript).

Feel free to write a better library. Axolotl/Signal doesn't have this
option without someone setting lawyers on you. That's why we had to
switch away from it.

> 2. XMPP environment integration
> I also had some concerns regarding the integration and coherence with the
> current XMPP XEPs and syntax.
> 2.1. OMEMO nodes name syntax
> Having node names that use the camelCase syntax is not something that I've
> encountered since the vCard tag in XEP-0054: vcard-temp. I'd prefer to stick
> with the kebab-case (lower-case-dash-separated syntax) like we have in the
> rest of the XEPs. What do you think?

Cosmetic, so this is not a hill to die upon, but all things being
equal I'd prefer consistency.

> 2.2. Current usage of PEP
> This feedback is related to the previous message that I sent on this ML
> regarding XEP-0163: Personal Eventing Protocol a couple of days ago (see
> https://mail.jabber.org/pipermail/standards/2017-January/031811.html).
> The current usage of PEP is, for me, not optimal and overly complex. Having
> a list of devices that needs to be synchronized on a node and their related
> bundles on some others brings race-conditions issues (actually mentioned in
> the Example 2.) and forces the clients to implement extra checks to ensure
> that everything is properly synchronized.
> Proposal :
> I propose to simply publish the bundles on several items in one unique
> "urx:xmpp:omemo:0" node. Each item ID will be the device ID.
> To discover the device ID list a simple
> http://jabber.org/protocol/disco#items query would then be sufficient and
> will rely on existing PEP/Pubsub implementations (client and server wise).
> Furthermore, each client could be instantly notified when a device has been
> added or retracted from the list.
> A similar behavior has already been standardized in XEP-0277: Microblogging
> over XMPP.

This would seem a better design, indeed.

> This seems to already work with servers like Metronome and ejabberd (not
> Prosody for now) and should not cause issues with existing OMEMO
> implementations that are still based on Axolotl and using the
> eu.siacs.conversations.axolotl namespace.
> Regards,
> Timothée Jaussoin aka edhelas
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list