[Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals
edhelas at movim.eu
Wed Jan 18 07:24:32 UTC 2017
On 09/01/2017 11:24, Dave Cridland wrote:
> On 6 January 2017 at 08:36, Jaussoin Timothée <edhelas at movim.eu> wrote:
>> 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
>> 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
> 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
>> 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.
>> Timothée Jaussoin aka edhelas
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
Do you think it's a good idea to propose a Pull Request for those
changes? I can work on this in the upcoming days.
Also, even if I'm not coming physically to the Summit I'll join you
using video-conferencing and I'm planning to present my feedbacks. See
https://wiki.xmpp.org/web/Summit_21#Agenda on Friday.
More information about the Standards