[Standards] OMEMO Key Agreement

Kevin Smith kevin.smith at isode.com
Thu Jun 1 08:30:16 UTC 2017

On 1 Jun 2017, at 06:03, Daniel Gultsch <daniel at gultsch.de> wrote:
> Hi,
> a lot of what Dave said about future proofing spoke to me and I'm
> starting to think he (and the others) are right.
> It makes me wonder if we should work towards making OMEMO a good
> standard for a more distant future. In the past a lot of valid changes
> to OMEMO have been dismissed because they can not be implemented right
> now. What if we put all those changes in? (Element encryption, not
> using multiple PEP nodes for multiple devices, and so on). It will
> surely take time to properly define all that. But there is no rush. We
> have a pretty good thing going with 'siacs-omemo' right now. We can
> use that for the foreseeable future and switch to a no-compromise
> OMEMO once it's truly done.
> We could change the current OMEMO XEP to reflect what is actually
> implemented right now with 'siacs-OMEMO'. It would become an
> Informational XEP (or maybe historical). At the same time we start
> working on 'OMEMO-NEXT'. A new standards track XEP that incorporates
> all the good suggestions that aren't really viable right now but will
> be in the future once implementations have caught up. (Like the
> multiple items in a PEP node for example). I always said that
> Element-Encryption (stanza-content) is nice to have. It just takes
> time to define properly. Let's take that time for OMEMO-NEXT. And most
> importantly we don't have to worry about being Signal compatible with
> that one and can use crypto primitives that are future proof. I
> appreciate Remko was trying to make it work with OMEMO Key Agreement
> v2 but rolling the dice again and again until the key matches some
> criteria doesn't sound like something that should be in a standard.
> Client authors who are looking for a short term solution (and can live
> with the downsides) can implement OMEMO while all the protocol work
> would go into OMEMO-NEXT.

I think this is nearly a sensible compromise, given where we are. The only change I think it needs is that logically 384 should remain Standards Track and Experimental, and would be where these “OMEMO-NEXT” things are developed, as you’d expect from the XSF’s normal process, and we can publish OMEMO-SIACS as a new, Historical, XEP to document existing behaviour (which isn’t what’s in or has ever been in 384, AFAIUI).


More information about the Standards mailing list