[Standards] OMEMO Discussion Summary 2017

Tobias Markmann tmarkmann at googlemail.com
Wed Jun 21 14:35:53 UTC 2017


Here my long overdue summary of recent OMEMO discussions. Feel free to
point out errors and what not.


The OMEMO protocol [0, 1] aims to bring end-to-end security to XMPP. It is
currently based on the Signal [2] protocol. At its core it is based on
elliptic-curve cryptography and symmetric cryptography.

This email aims to summarise the recent discussions around OMEMO in the
previous months, provide a short history of the XSF related development of
the XEP and the discussions. It does not reference every discussion
contribution and is by no means complete. However, I've tried my best. For
full history, see the mailing list archives.

Please let me know if I understood some parts of the discussion wrong or
wrongly paraphrased people.

OMEMO is an end-to-end security protocol for XMPP that originated from
Google Summer of Code. It was a ProtoXEP for some time that got widely
implemented. It was changed in the process of becoming a XSF XEP. Now
further development of the XSF XEP is about to happen. Currently there are:

    a) SIACS OMEMO (implemented in the wild) using the Signal protocol
    b) XSF OMEMO (not implemented anywhere) which currently uses Olm
instead of the Signal protocol

There are different proposals to move forward form here:
    c) Using OMEMO Double Ratchet (ODR) and X3DH from Andreas Straub
(original OMEMO author) https://github.com/xsf/xeps/pull/460
    d) Continue using Olm and updating upon it from Remko Tronçon:

There are basically two major groups in the discussion:
    e) We should follow what libsignal does (X3DH) as currently all SIACS
OMEMO implementation use libsignal to provide OMEMO.

   -      This is currently only available in libsignal and the java signal
   library and bindings to them. Both available under GPLv3.

    f) We should go with Olm and more standard crypto primitives as they
can be found in OpenSSL, BouncyCastle, etc.

   - The argument for this approach is that it uses general crypto that's
   been well known and tested. It's widely available in most programming
   environments. It is also provided by libraries with a liberal software
   license (MIT/BSD/Apache and that like). This provides more choice on how to
   implement the protocol and the crypto primitives do not have to be
   implemented by the chat application developers.


Furthermore, regardless on how the OMEMO development continues, a lot media
points to the XSF XEP when mentioning OMEMO and that doesn't currently
reflect what's implemented in the wild. Thus the suggestion of Kevin Smith
was to specify what's currently implemented in the wild as a new version in
XEP-0384 which people can refer to. New developments then can continue from
there in XEP-0384 following the usual XSF process of discussions of
proposed changes on the mailing list, consensus, etc.

With that, the media and client developers can point to the version of
XEP-0384 that is currently widely implemented and the XSF community is free
to improve the end-to-end security standard OMEMO in XEP-0384 without the
constraints of existing implementations which might follow way proposal e)
or proposal f) or something else entirely.

Daniel wrote a PR that brings the XSF OMEMO XEP in line with the
implementations out there https://github.com/xsf/xeps/pull/470 .

Timeline of OMEMO as a XSF specification and surrounding recent discussions
2015-10-28: 1st proposal of OMEMO as XEP

2015-11-13: Thijs Alkemade raises concerts about the proposed
specification, as the underlying crypto protocol is not publicly specified
and has only a single implementation, a GPLv3 licensed library

2015-12-23: Andreas Straub clarifies the specification used in OMEMO and
the various TextSecure/Signal protocol versions around.

2015-12-25: Thijs Alkemade states that the publicly available TextSecure v2
protocol documentation is insufficient and doesn't specify the hash used in
their HKDF. He points to the OLM specification of the Matrix project as an
example of a very similar protocol with a detailed specification including
the crypto primitives to be used.

2016-04-12: Dave Cridland also points to the Olm specification, which is a
based on Axolotl but decently specified.

2016-10-01: Daniel Gultsch points to his PR that changes the OMEMO ProtoXEP
to use the Olm specification and includes some minor improvements that came
up in the OMEMO audit.

2016-10-31: The new version of the OMEMO ProtoXEP based on Olm is published
at https://xmpp.org/extensions/inbox/omemo.html

2016-11-24: The council votes on the OMEMO ProtoXEP, based on Olm.

2017-03-30: Remko Tronçon raises the issue of the an upcoming version (
https://github.com/xsf/xeps/pull/460 ) of OMEMO requiring X3DH (
https://whispersystems.org/docs/specifications/xeddsa/ ) key exchange for
the establishment of a shared secret. The issue comes down to X3DH only
having a single GPLd implementation in libsignal and as a developer he does
not want to implement crypto primitives for X3DH himself.

2017-05-17: Dave Cridland starts a discussion about the future of the OMEMO
XEP and why there is a plan from the OMEMO authors to move away from Olm
after it has been standardised using Olm crypto
https://mail.jabber.org/pipermail/standards/2017-May/032632.html .

2017-05-29: Remko Tronçon starts a new discussion to change the protocol to
not require the X3DH algorithm
https://mail.jabber.org/pipermail/standards/2017-May/032765.html .

2017-06-02: Kevin Smith suggests putting the current state of deployed
OMEMO in the XEP and publishing it under a new version so it has a stable
identifier that can be pointed to.
https://mail.jabber.org/pipermail/standards/2017-June/032863.html Daniel
Gultsch is fine with that compromise
https://mail.jabber.org/pipermail/standards/2017-June/032864.html .

2017-06-07: Kevin Smith repeats the current plan to move forward with OMEMO
spec. This means publishing the currently deployed SIACS OMEMO as the ne xt
OMEMO version and continue development from there.

2017-06-08: Dave Cridland furthermore clarifies the current plan, which is
to specify what is currently deployed in the OMEMO XEP and then advance the
XEP with more XSF community consensus.

[0] https://en.wikipedia.org/wiki/OMEMO
[1] https://conversations.im/omemo/
[2] https://whispersystems.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170621/1893a3c3/attachment-0001.html>

More information about the Standards mailing list