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 <f...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
