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
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
