I agree! I think that's a very pragmatic approach, and reflects the reality of currently deployed clients.
On Wed, Jun 7, 2017 at 6:48 AM, Florian Schmaus <[email protected]> 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. As consequence, end-users will continue to use an old > version of XEP-0384 for the foreseeable future. > > I do not see any compelling reason why we would want that. It means that > there will be no canonical and official place within the XSF where the > currently used protocol can further evolve, where we can address > security issues and specify new features. We would bury one of the most > successfully deployed XMPP end-to-end encryption system for the masses. > > Instead I suggest we go with Andreas Straub's OMEMO update [2], which > attempts to specify a wire format, depends exclusively on open > standards, and keeps the audited and battle-tested crypto every OMEMO > implementation currently uses. > > There were some arguments that XEdDSA is not common crypto and therefore > should be avoided. I am supportive and welcome the work on a successor > of OMEMO which does use different crypto primitives. But we have a > responsibility not to leave the users standing in the rain. Therefore > the work on the OMEMO successor should happen under a *new* XEP number. > > - Florian > > 1: maybe not this week > 2: https://github.com/xsf/xeps/pull/460 > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
