[FEATURE] Omemo support

[marxistvegan]

I know thing are in the early stages. however omemo this would be good as it is a more crypto level. If you are interested in supporting it of course

[tcz001]

Related with #199

[olabini]

As mentioned in #199, we are not so interested in supporting OMEMO right now, or in the near future - we are quite happy with OTR and some of the design decisions of OMEMO are far enough from being privacy preserving that I'm uncomfortable with it.

[iNPUTmice]

Hi,

merging what you said in #199 into a single thread

and relies on multicasting all messages to every place

I don't understand what you mean by relies on multicasting. If by multicast you mean carbons than this is not true. It allows you to use carbons. But it doesn't rely on it. You can just as well send the message to a single resource. I don't understand why you would want to do this. But you can.

design decisions of OMEMO are far enough from being privacy preserving that I'm uncomfortable with it.

what design decisions are those? OMEMO and OTR share almost the same cryptographic properties in regards of forward secrecy.

[iNPUTmice]

we are quite happy with OTR

when reading issues #301 or commit messages like the one from 43bf6e0 that contain statements like: It's unclear how we should handle this case.

It kinda sounds like you aren't really happy with OTR. Reading through your commit history kinda feels like you are slowly but surely discovering all the problems with OTR over XMPP I discovered myself two years ago when I first got into all this.

The main things:

• It is unclear what resource to send to
• It is completely unclear when to start and when to end an OTR session. Do I end an OTR session when I restart the program? Or when I close the window? How does my chat partner know that? What happens if the end otr messages gets lost because of a bad connection? Even if I come up with a strategy that makes somewhat sense. How do I make sure the other client is using the same?

OTR was never designed for a protocol like XMPP. I'm really not just promoting my own protocol. (Take a look at OX if you want another working alternative) I'm really just trying to save you a lot of trouble and I do want you to succeed because people need a desktop client that is not Pidgin or Gajim.

You by the way never answered the question what design decisions of OMEMO you don't like.

If you want to stick with OTR - and I urge you not to - please at least read XEP-0364: Current Off-the-Record Messaging Usage

[olabini]

Would you mind explaining in what way OMEMO solves those problems?

The feature I strongly dislike with OMEMO is the multicast stuff.

I think it's interesting that you say OTR was not designed for XMPP - it actually was.

In general, the problem I have is that the more code we add, the more places that can go wrong. Adding a new protocol - ANY new protocol - means a huge amount of complexity, and I'm strongly against that unless the benefits outweigh the cost.

Incidentally, the comments you note have now been fixed.

[iNPUTmice]

Would you mind explaining in what way OMEMO solves those problems?

OMEMO has one long standing session that exists over the entire life time of the program (until you uninstall it or recreate the account) thus the question on how and when to tear down a session and setup a new one doesn't exist.

Having the long standing session makes it possible to send messages to offline contacts. (Which OTR can not do.)

The feature I strongly dislike with OMEMO is the multicast stuff.

OMEMO has the option to send messages to multiple clients. Every device has it's own key. (Meaning you keep a session with every device) and you can selectively decide what device(s) to send to. If your contact is online with his desktop and his mobile you can decide to send the message to all of them - or if for some reason you decide to send only to one you have this option as well. (To be honest I don't see why as long as you trust both devices but you can.)

I think it's interesting that you say OTR was not designed for XMPP - it actually was.

OTR was designed to be protocol agnostic. OTRv3 for example as mechanisms in place to discard messages that weren't intended for that exact device (and thus avoiding error loops). XMPP can do that out of the box.
But let me rephrase my previous statement to: OTR was not designed for modern day instant messaging. OTR was designed at a time where you start your computer. Log in to ICQ. See who is online. Start a chat with someone. Start an encrypted chat. Exchange messages. Shutdown your computer. We no longer live in this times. We are online constantly. Switching between devices. Tablet, Desktop, Phone. We can't expect our contacts to know what device we are currently using. We even want to switch devices while engaged in a conversation. OTR was not designed for that. OMEMO is.

There is this 5 minute lightning talk from 32c3 that explains the benefits: http://www.youtube.com/watch?v=zMp2jAHquns&t=1h23m07s

[olabini]

I understand all those points. However, they still doesn't convince me to consider OMEMO for implementation.
Incidentally, you don't need a long lived session in order to do offline messages. We are currently working on OTRv4 which will have support for offline messages as well.

I think I've made my opinion quite clear here. The benefits of a new protocol like OMEMO doesn't outweigh the cost of complexity for us.

[the-solipsist]

I think it's interesting that you say OTR was not designed for XMPP - it actually was.

This is not correct. OTR was meant to be protocol agnostic. Full stanza encryption is not supported by OTR, nor is advertising OTR capability through XMPP presence. Listen to this IETF89 session on E2E encryption in XMPP if you're interested in learning more about the mismatch.

Edit: Here's Moxie Marlinspike on the problems with OTR.

People working on end-to-end encryption in XMPP have been speaking about these issues for years at venues like IETF meetings and XSF mailing lists, and that is precisely why draft-miller-xmpp-e2e and OMEMO and OX have been proposed. People wouldn't have been proposing all of those if OTR was technically sufficient to work well with XMPP.

The feature I strongly dislike with OMEMO is the multicast stuff

The "multicast" design feature you are faulting OMEMO for is actually an XMPP feature (Carbons). OTR does not work well with Carbons, and it does not support usage on multiple clients. Even mpOTR has been a dead end. OTRv4 doesn't even have specs yet, leave alone implementations, and it is unclear to me what OTRv4 solves that OMEMO doesn't already do. In any case, OTRv4 needs to include the Axolotl ratchet, which OMEMO is already based on.

We are currently working on OTRv4 which will have support for offline messages as well.

At any rate, as you yourself note, OTRv4 will have to be included. From what I understand, OTRv4 won't work with OTRv3. Given this, both will have to be supported, and that will also increase complexity. So if you're okay with increasing complexity for OTRv4, is there a rationale for arguing that OTRv4 will be better than OMEMO?

The main argument that I can think of for preferring OTR over OMEMO or OX is if you wish to work with protocols other than XMPP (since OMEMO and OX are XMPP-specific, while OTR isn't). But clearly, Coy wishes to be an XMPP client, and not a multi-protocol client. If that isn't the argument, and complexity by itself isn't, then what is?

[olabini]

The multicast "feature" is not about XMPP carbons. OTR doesn't work with carbons, which I'm fine with - I want a conversation to be with exactly one endpoint.

OTRv4 will of course be backwards compatible with OTRv3 - it's a new version.

I've tried to make myself abundantly clear here - OMEMO and other non-OTR solutions are not on the roadmap. If that's something you and all the other people coming here are uncomfortable with, feel free to fork the project and implement OMEMO - this is an open source project.

[SamWhited]

The multicast "feature" is not about XMPP carbons. OTR doesn't work with carbons, which I'm fine with - I want a conversation to be with exactly one endpoint.

That's fine, OMEMO supports that too; carbons or no, OMEMO does not require multicast, it's perfectly optional.