[Standards] OMEMO Key Agreement

Daniel Gultsch daniel at gultsch.de
Thu Jun 1 05:03:42 UTC 2017


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.

- Daniel


More information about the Standards mailing list