[Standards] OMEMO Discussion Summary 2017

Dave Cridland dave at cridland.net
Wed Jun 21 22:03:53 UTC 2017


On 21 June 2017 at 15:35, Tobias Markmann <tmarkmann at googlemail.com> wrote:
> Here my long overdue summary of recent OMEMO discussions. Feel free to point
> out errors and what not.

The only thing I'd add is a little history. I might wax a little
cynical in this.

When I started working with XMPP (I wrote a quick and dirty XMPP
client in 24 hours), end-to-end encryption already had at least three
designs, and I think a fourth was well on the way.

One was based on libotr, Ian Goldberg et al's original Off The Record
Messaging. It was actually only specified very recently in XMPP,
though implemented as early as 2004 I think. I think this reached
roughly the same levels of implementation as OMEMO - that is,
exclusively a single library, but wrapped into a number of popular
client projects.

This was the "newer" kid on the block, though, the original being
CMS-based (RFC 3923). Think S/MIME for XMPP, and you're about right.
And where there's S/MIME, there's sure to be PGP - and sure enough,
XEP-0027 was around, and, as I recall, used by about five people who
bought lots of tinned food in bulk (I'm kidding - maybe - Psi had an
implementation and possibly other clients too, but I didn't see it
used much). RFC 3923 was, as befits anything based on S/MIME, used by
absolutely nobody at all. Both failed because they didn't really work
well, and were ugly as sin, too.

The new one on the horizon was ESessions. ESessions was driven by a
single developer, and used some fairly exotic crypto to perform
roughly the same as OTR or OMEMO, albeit using older cryptographic
primitives. It had one implementation (Gajim). It was last updated a
decade ago. ESessions largely failed because it used exotic crypto
primitives. These never got an audit, as far as I'm aware, but the
fact they even needed one is a problem. Note that from a technical
standpoint, there's really nothing at all wrong with the crypto in
ESessions as far as I know. Nobody suggested there was, either.

Then a few years on, and Silent Circle did SCIMP, which I'll count
here because although not standardized it was running on XMPP.

Every single one of these is now long dead, though OTR limps on in a
few clients. (Unless you count OMEMO as being an ultimate derivative
of OTR and SCIMP via Signal, of course).

There's now three that I know of (or suspect strongly exist):

OMEMO - single library, wrapped in a handful of clients. Some of those
clients are very well deployed (although this was also true of
XEP-0027 with Psi, OTR with Gaim/Pidgin, and ESessions with Gajim).
OX - Like XEP-0027 with the deployed base of RFC 3923.
MIKEY-SAKKE - Now I *think* there are XMPP-based implementations of
this around the "Secure Chorus" market, but I've not actually seen
anything yet. It's a offline key escrow IBE system, designed for
governments and enterprises (ie, not consumers). The UK actually
mandates its use in some cases (mostly to talk to it). Take a moment
to enjoy the hysterical web search results.

So it seems that the XMPP community is great at end-to-end encryption
- in as much as we produce an astounding number of proposals - but
less good at making them actually work in the market.

With OX dead in the water, that leaves MIKEY-SAKKE, for the enterprise
and (UK) government, and OMEMO, for the consumer.

It's mildly annoying to have two entirely incompatible crypto
protocols, but in fairness they're two almost entirely incompatible
markets.

I would like not to have to update this history of failed protocols in
another few years, therefore I would like OMEMO to not fall into any
of the failure cases of previous attempts. I'd like to see lots of
fully independent interoperable implementations. I'd like to see use
of well-established, widely used cryptographic primitives.

Dave.


More information about the Standards mailing list