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

Jaussoin Timothée edhelas at movim.eu
Fri Jan 6 08:36:14 UTC 2017


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).

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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170106/e8d66d6c/attachment-0001.html>


More information about the Standards mailing list