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

Jaussoin Timothée 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:
>> 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
>> _______________________________________________
>>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
Hi again,

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.

Regards,

Timothée Jaussoin


More information about the Standards mailing list