[Standards] Don't let today be the day we bury OMEMO

Florian Schmaus flo at geekplace.eu
Thu Jun 15 22:05:35 UTC 2017


On 07.06.2017 18:03, Kevin Smith wrote:
> This feels somewhat like trying to torpedo the current compromise that’s on the table, so I’d like to make some comments.

I try to point out that going with this compromise will have a huge
negative impact developing an useable open-standard end-to-end
encryption mechanism for end users.

> On 7 Jun 2017, at 14:48, Florian Schmaus <flo at geekplace.eu> wrote:
>> The council will likely soon [1] decide if the currently used OMEMO
>> protocol will be published as the next version of XEP-0384. While that
>> is great, the plan is to shift following versions of that XEP away from
>> the Double Ratchet Algorithm using XEdDSA. This means that newer
>> versions will be incompatible with all currently deployed OMEMO
>> implementations.
> 
> This probably needs clarifying. There are no currently deployed OMEMO implementations (of which I’m aware)
The outcome of the XSF's GSOC 2015 project [4] *is* OMEMO. I believe in
rough consensus and running code. And that running code says there are
many deployed OMEMO implementations.

>> As consequence, end-users will continue to use an old
>> version of XEP-0384 for the foreseeable future.
> 
> This seems an odd argument to make on behalf of clients that were quite willing to implement a version of the protocol that was never standardis
> If they had been that concerned about their compliance to XEP-0384

In some cases people don't care about the compliance to a particular
XEP. What matters is interoperability. And since the OMEMO ProtoXEP [3]
had such a high traction, and for the reasons discussed, the ProtoXEP
got implemented, while no one ever implemented XEP-0384 (to my knowledge).
>> there will be no canonical and official place within the XSF where the
>> currently used protocol can further evolve,
> 
> That’s not really true, is it? Unlike currently (where the currently used protocol isn’t canonical, official, or within the XSF), this compromise does provide somewhere for the protocol to develop, as is always intended with Experimental XEPs, while also allowing existing clients to claim they implement OMEMO/XEP-0384, which they currently can't.

You propose to change/replace major parts of the currently used Double
Ratchet as specified in [1] in the future development of OMEMO. I
believe this is very dangerous.

That "compromise" means that no further OMEMO improvements, like Andy's
PR [2], will get into a XEP. Instead you want a strict cut, leave the
current implementations in the rain and to start new from scratch.

But we can't affording breaking changes for the end user. We need for
the foreseeable future a place where the work on OMEMO can continue and
is coordinated. And I think it is sensible and beneficial if this place
would be the XSF.

Again, I'd welcome and support further end-to-end encryption XEPs. And I
think you should create a new one instead of trying to bend OMEMO so
much that the final result is no longer OMEMO.

- Florian

1: https://whispersystems.org/docs/specifications/doubleratchet/
2: https://github.com/xsf/xeps/pull/460
3: https://conversations.im/omemo/xep-omemo.html
4: http://conversationsgsoc2015.blogspot.de/2015/09/omemo.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170616/9a13a661/attachment.sig>


More information about the Standards mailing list