OK. Let's move on then. It seems like people are mostly fine with The Compromise™. Council will vote on publishing my PR as OMEMO version 0.3 next week. And I currently have no reason to expect that it will get vetoed.
Afterwards we need to decide on a new author for the XEP to drive the change towards OMEMO-NEXT. That's a pretty big responsibility if we don't want OMEMO to go down the same road as its predecessors. Questions for OMEMO-NEXT for the new author to collect feedback on. (Each of them deserves it's own thread) - Do we want to break up the wire format into XML. (Both Olm and Signalprotocol are using some binary encoding format that either is protobuf or tries to be) - Do we want to continue using XedDSA or do we want to use two separate keys for signing and encrypting (Those are the two sane alternatives I guess) - Do we want to move all devices into separate items of one node. Do we keep the index-node/meta node to reduce traffic. Is there a better way in Pubsub? - Do we want to have stanza-content encryption and if so how do we do it? -- Shower thought I just had on stanza-content encryption; What if we allow stanza-content encryption only for messages and then define a second XEP that does OMEMO-based e2e-streams (maybe reusing semantics from previous XEPs) to do IQ communication. That way normal messages will still land in MAM and can be handled by carbons and so forth but we don't have the overhead of having to encrypt each and every stanza individually if we want to do a lengthier IQ-based exchange. The e2e-stream/IQ-transport thingy could thus be optional for clients that like to do IQ-based things. But I figure normal IM-clients will rarely do IQ stuff anyway these days (with each other) Please if you want to respond to any of these questions do so in separate threads or else things will get really cluttered here. And you might want to wait for the new author to get picked otherwise no one will feel responsible to collect your feedback. cheers Daniel 2017-06-21 16:35 GMT+02:00 Tobias Markmann <tmarkm...@googlemail.com>: > Hi, > > Here my long overdue summary of recent OMEMO discussions. Feel free to point > out errors and what not. > > Cheers, > Tobi > > > > Overview > -------- > 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. > > TLDR > ---- > 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: > https://github.com/xsf/xeps/pull/463 > > 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 > https://mail.jabber.org/pipermail/standards/2015-October/030544.html > > 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 > https://mail.jabber.org/pipermail/standards/2015-November/030622.html > > 2015-12-23: Andreas Straub clarifies the specification used in OMEMO and the > various TextSecure/Signal protocol versions around. > https://mail.jabber.org/pipermail/standards/2015-December/030725.html > > 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. > https://mail.jabber.org/pipermail/standards/2015-December/030727.html > > 2016-04-12: Dave Cridland also points to the Olm specification, which is a > based on Axolotl but decently specified. > https://mail.jabber.org/pipermail/standards/2016-April/031026.html > > 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. > https://mail.jabber.org/pipermail/standards/2016-October/031460.html > > 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. > https://mail.jabber.org/pipermail/standards/2016-November/031646.html > > 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. > http://markmail.org/message/dkilh72vjbyo22zn > > 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. > https://mail.jabber.org/pipermail/standards/2017-June/032898.html > > 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. > https://mail.jabber.org/pipermail/standards/2017-June/032911.html > > References > ---------- > [0] https://en.wikipedia.org/wiki/OMEMO > [1] https://conversations.im/omemo/ > [2] https://whispersystems.org/ > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
