Addressed to Arasp
Hey, I was writing you on XMPP but I decided to hit you by HTTP instead. I’ve been looking more into encryption for XMPP, since I’m still having problems with it. I discovered that the standard for the encryption and key-sharing schemes used by XMPP’s new standard “OMEMO” XEP-0384 (https://xmpp.org/extensions/xep-0384.html) uses the Double Ratchet encryption scheme and the X3DH key exchange protocol, both published by Signal (https://signal.org/docs/specifications/doubleratchet/ and https://www.signal.org/docs/specifications/x3dh/). I want to focus in particular on the use that the XEP’s authors, Andreas Straub, Daniel Gultsch, Tim Henkes, Klaus Herberth, Paul Schaub, and Marvin Wißfeld, envision for their system:
The use case for OMEMO is a situation where the content of a conversation needs to be protected, but where the servers the message passes by can’t be trusted to keep the content of the message secret. For example when information that is under strict embargo needs to within an organization and the server administrator is not one of the persons cleared to see the information or when a couple is exchanging intimate messages and they want to avoid leaking of those messages to the server administrator. The OMEMO protocol protects against passive and active attackers which are able to read, modify, replay, delay and delete messages.
The image here is of a nefarious snooper, the so-called “Eve” always listening in, seeking to intercept and distort the message. Against these sorts of intruders, the protocol is robust. I trust it to transmit xmpp “stanzas” between us unmollested on the network, while “guaranteeing” all these amazing things:
- Confidentiality: Nobody else except sender and receiver is able to read the content of a message.
- Forward Secrecy: Compromised key material does not compromise previous message exchanges. It has been demonstrated, that OMEMO provides only weak forward secrecy (it protects the session key only once both parties complete the key exchange).
- Break-in Recovery: A session which has been compromised due to leakage of key material recovers from the compromise after a few communication rounds.
- Authentication: Every peer is able to authenticate the sender or receiver of a message, even if the details of the authentication process is out-of-scope for this specification.
Integrity: Every peer can ensure that a message was not changed by any intermediate node.
- Deniability: X3DH is weakly offline deniable and provides no online deniability, as far as the research shows.
- Asynchronicity: The usability of the protocol does not depend on the online status of any participant.
However, the protocol is limited from its inception:
OMEMO is not intended to protect against … an attacker [who] has permanent access to your device. In this case, the attacker may extract decrypted messages from the device, eg. from the applications database. … The OMEMO protocol does not protect against attackers who rely on metadata and traffic analysis.
One wonders: what sort of attackers are they who “rely on metadata and traffic analysis?”; who “has permanent access to your device”? I shudder to imagine. And what secrets lie in the “applications database?” Is it the database shared by several applications, or the “application’s database”, the database belonging to a particular application? The primary image is that the machine is stolen or, as noted by the protocol, “lost”. But I note that a significant danger is in the messaging client itself: the client handles all messages as plaintext, encrypting and decrypting them for the user. One wonders whether the client is suspect: might this be how the nefarious analyser of meta and traffic data works? The committee concludes, laconically: “Trust management is a difficult topic, which is out of scope of this document.” Nevertheless, we are left with one hope:
The quality of the verification of the conversation participants[’] OMEMO identity keys determines the level of protection OMEMO offers.
In other words, if the client is trust-worthy (which it should be — it’s your machine, after all!) and you believe that the person on the other end of the wire is who they say they are, then you’re golden, unless the adversary is someone who can monitor network traffic: even if they can’t read or modify your messages, they can still see who’s sending what to whom when and can thereby infer all sorts of nasty things about you.
https://www.rfc-editor.org/rfc/rfc2778: A Model for Presence and Instant Messaging
https://datatracker.ietf.org/doc/html/rfc6121: XMPP IM
It’s interesting to note, first, that using XMPP for instant messaging is already an extension on the basic protocol. XMPP isn’t like the web – it’s like HTTP. IM is XMPP’s killer app, as the web is for HTTP. The difference is that IM long predates XMPP. But XMPP is much more than IM.
Now, to follow r0ml’s law, it will eventually become possible to transmit instructions to XMPP clients over XMPP, much like one can send and run javascript to a web browser over http. There is a single limitation: encoding the instructions. How? What language?
