OMEMO is not intended to protect against the following use cases:
+ When receiving an OMEMOKeyExchange, the receiving device checks if it already has a Double Ratchet session with the sending device. If that is the case, the device compares the ephemeral public key stored in the Double Ratchet state with the ephemeral public key in the OMEMOKeyExchange.proto structure. If both are equal, the receiving device only processes the OMEMOAuthenticatedMessage.proto contained in the OMEMOKeyExchange.proto. Otherwise, it processes the whole OMEMOKeyExchange.proto structure. +
@@ -321,7 +338,7 @@
- To participate in OMEMO-encrypted chats, clients need to set up an OMEMO library and generate a device id, which is a randomly generated integer between 1 and 2^31 - 1. The device id must be unique for the account. + To participate in OMEMO-encrypted chats, clients need to set up an OMEMO library and generate a device id, which is a randomly generated integer between 1 and 2^31 - 1 (the positive numbers of a signed 32 bit integer, without 0). The device id must be unique for the account.
Furthermore, a device MUST publish its IdentityKey, a signed PreKey, and a list of PreKeys. This tuple is called a bundle and is provided by OMEMO libraries. Bundles are maintained as multiple items in a PEP node called &nsbundles;. Each bundle MUST be stored in a seperate item. The item id MUST be set to the device id.
-A bundle is an element called 'bundle' in the &ns; namespace. It has a child element called ‘spk’ that contains the public part of the signed PreKey as base64 encoded data, a child element called ‘spks’ that contains the signed PreKey signature as base64 encoded data and a child element called ‘ik’ that contains the public part of the IdentityKey as base64 encoded data. PreKeys are multiple elements called ‘pk’ that each contain the public part of one PreKey as base64 encoded data. PreKeys are wrapped in an element called ‘prekeys’ which is a child of the bundle element. The ‘spk’ and the ‘pk’s are tagged with an ‘id’-attribute which is a positive integer that uniquely identifies the keys. The ‘spk’ and the ‘pk’s are considered separate, which means that an ‘spk’ can have the same ‘id’ as a ‘pk’. These ids are used to save bandwidth during key exchanges, which refer to the keys using their id instead of their full public parts.
+A bundle is an element called 'bundle' in the &ns; namespace. It has a child element called ‘spk’ that contains the public part of the signed PreKey as base64 encoded data, a child element called ‘spks’ that contains the signed PreKey signature as base64 encoded data and a child element called ‘ik’ that contains the public part of the IdentityKey as base64 encoded data. PreKeys are multiple elements called ‘pk’ that each contain the public part of one PreKey as base64 encoded data. PreKeys are wrapped in an element called ‘prekeys’ which is a child of the bundle element. The ‘spk’ and the ‘pk’s are tagged with an ‘id’-attribute which is a positive integer between 1 and 2^31 - 1 (the positive numbers of a signed 32 bit integer, without 0) that uniquely identifies the keys. The ‘spk’ and the ‘pk’s are considered separate, which means that an ‘spk’ can have the same ‘id’ as a ‘pk’. These ids are used to save bandwidth during key exchanges, which refer to the keys using their id instead of their full public parts.
When publishing bundles a client MUST make sure that the &nsbundles; node is configured to store multiple items. This is not the default with &xep0163;. If the node doesn’t exist yet it can be configured on the fly by using publish-options as described in XEP-0060 §7.1.5. The value for 'pubsub#max_items' in publish_options MUST be set to 'max'. If the node did exist and was configured differently the bundle publication will fail. Clients MUST then reconfigure the node as described in XEP-0060 §8.2.
An OMEMO SCE &content; element
@@ -514,11 +530,13 @@- An OMEMO encrypted message is specified to include an <encrypted> element in the &ns; namespace. It always contains two child nodes, the <header> and the &payload; element. - The <header> element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple <keys> elements, each with an attribute 'jid' of one of the recipients bare JIDs as well as one or multiple <key> elements. + An OMEMO encrypted message is specified to include an <encrypted> element in the &ns; namespace. It contains up to two child nodes, the <header> and the &payload; element. The <header> element must always be present, the &payload; element must be present unless an empty OMEMO message is sent, as described below. + The <header> element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple <keys> elements, each with an attribute 'jid' of one of the recipients bare JIDs, as well as one or multiple <key> elements. A <key> element has an attribute named 'rid' referencing the device id of the recipient device, and an attribute named 'kex' which defaults to 'false' and indicates if the enclosed encrypted message includes a key exchange. The key and HMAC encrypted using the long-standing OMEMO session for that recipient device are encoded using base64 and placed as text content into the <key> element. The encrypted &content; element is encoded using base64 and placed as text content into the &payload; element.
+ +A special case are empty OMEMO messages, which are used in various places throughout the protocol purely to manage sessions and not to transfer content. With empty OMEMO messages, the step of creating and encrypting the &payload; element is skipped. Instead of encrypting the key and authentication tag of the &payload; ciphertext with the Double Ratchet session, 32 zero-bytes are encrypted with the Double Ratchet session directly. The resulting OMEMOKeyExchange or OMEMOAuthenticatedMessage are put into <key> elements as usual, but the &payload; element is omitted altogether, so that the <encrypted> element only contains a <header>.
Note: OMEMO encrypted group chats are currently specified to work with &xep0045;. This XEP might be updated in the future to specify the usage of OMEMO in conjunction with &xep0369;.
+NOTE: OMEMO encrypted group chats are currently specified to work with &xep0045;. This XEP might be updated in the future to specify the usage of OMEMO in conjunction with &xep0369;.
A Multi-User Chat room that supports OMEMO MUST be configured non-anonymous and SHOULD be configured members-only.
A participant wanting to send a message to a group chat MUST first retrieve the members list and then fetch the device list for each member (via pubsub and to their real JIDs) and then subsequently fetch all bundles referenced by the device lists.
Before publishing a freshly generated device id for the first time, a device MUST check whether that device id already exists, and if so, generate a new one.
Clients SHOULD NOT immediately fetch the bundle and build a session as soon as a new device is announced. Before the first message is exchanged, the contact does not know which PreKey has been used (or, in fact, that any PreKey was used at all). As they have not had a chance to remove the used PreKey from their bundle announcement, this could lead to collisions where both Alice and Bob pick the same PreKey to build a session with a specific device. As each PreKey SHOULD only be used once, the party that sends their initial OMEMOKeyExchange later loses this race condition. This means that they think they have a valid session with the contact, when in reality their messages MAY be ignored by the other end. By postponing building sessions, the chance of such issues occurring can be drastically reduced. It is RECOMMENDED to construct sessions only immediately before sending a message.
-There are various reasons why decryption of an OMEMOKeyExchange or an OMEMOAuthenticatedMessage could fail. One reason is if the message was received twice and already decrypted once, in this case the client MUST ignore the decryption failure and not show any warnings/errors. In all other cases of decryption failure, clients SHOULD respond by forcibly doing a new key exchange and sending a new OMEMOKeyExchange with a potentially empty SCE payload. By building a new session with the original sender this way, the invalid session of the original sender will get overwritten with this newly created, valid session. This does NOT apply to the actual SCE content. If decrypting the SCE content fails, e.g. because the HMAC does not verify, this is not a reason to forcibly initiate a new key exchange.
+After receiving an OMEMOKeyExchange and successfully building a new session, the receiving device SHOULD automatically respond with an empty OMEMO message (as per Sending a message) to the source of the OMEMOKeyExchange. This is to notify the device that the session initiation was completed successfully and that the device can stop sending OMEMOKeyExchanges.
+When receiving a message that is not an OMEMOKeyExchange from a device there is no session with, clients SHOULD create a session with that device and notify it about the new session by responding with an empty OMEMO message as per Sending a message.
+There are various reasons why decryption of an OMEMOKeyExchange or an OMEMOAuthenticatedMessage could fail. One reason is if the message was received twice and already decrypted once, in this case the client MUST ignore the decryption failure and not show any warnings/errors. In all other cases of decryption failure, clients SHOULD notify their users (if applicable), so that the users know they potentially missed a message.
If an OMEMOKeyExchange is received as part of a message catch-up mechanism (like &xep0313;) and used to establish a new session with the sender, the client SHOULD postpone deletion of the private key corresponding to the used PreKey until after the catch-up is completed. If this is done, the client MUST send an OMEMO encrypted message with empty SCE payload right after the key exchange is completed, to forward the ratchet and to move away from the possibly double-used PreKey. This practice can mitigate the previously mentioned race condition by preventing message loss.
-When a client receives the first message for a given ratchet key with a counter of 53 or higher, it MUST send a heartbeat message. Heartbeat messages are normal OMEMO encrypted messages where the SCE payload does not include any elements. These heartbeat messages cause the ratchet to forward, thus consequent messages will have the counter restarted from 0.
+OMEMO's forward secrecy and backup/restore mechanisms don't play well together. Restoring old data can lead to desynchronized, "broken" sessions. Because these cases exist, clients MUST offer a way to manually replace broken sessions. It is advisable to have a session replacement option per recipient/per chat, if applicable. Otherwise, at least an application-global session reset MUST be available.
+When a client receives the first message for a given ratchet key with a counter of 53 or higher, it MUST send a heartbeat message. Heartbeat messages are empty OMEMO messages as per Sending a message. These heartbeat messages cause the ratchet to forward, thus consequent messages will have the counter restarted from 0.
When a client receives a message from a device id that is not on the device list, it SHOULD try to retrieve that user's devices node directly to ensure their local cached version of the devices list is up-to-date.
When the user of a client deactivates OMEMO for an account or globally, the client SHOULD delete the corresponding bundles and device ids from the PEP nodes. That way other clients should stop encrypting for that account.
While OMEMO uses a Pubsub Service (&xep0060;) on the user’s account it has more requirments than those defined in &xep0163;. The requirements are:
Clients MUST NOT use a newly built session to transmit data without user intervention. If a client were to opportunistically start using sessions for sending without asking the user whether to trust a device first, an attacker could publish a fake device for this user, which would then receive copies of all messages sent by/to this user. A client MAY use such "not (yet) trusted" sessions for decryption of received messages, but in that case it SHOULD indicate the untrusted nature of such messages to the user.
-When prompting the user for a trust decision regarding a key, the client SHOULD present the user with a fingerprint in the form of a hex-string, QR code, or other unique representation, such that it can be compared by the user. To ensure interoperability between clients and older versions of OMEMO, the fingerprint SHOULD be chosen to be the public part of the IdentityKey in its byte-encoded Curve25519 form (see the notes on XEdDSA and the byte-encoding of public keys in the X3DH protocol section for details). When displaying the fingerprint as a hex-string, one way to make it easier to compare the fingerprint is to split the hex-string into 8 substrings of 8 chars each, then coloring each 8-char group using &xep0392;. Lowercase letters are recommended when displaying the fingerprint as a hex-string.
+Clients MUST NOT use a newly built session to transmit data without user intervention. If a client were to opportunistically start using sessions for sending without asking the user whether to trust a device first, an attacker could publish a fake device for this user, which would then receive copies of all messages sent by/to this user. A client MAY use such "not (yet) trusted" sessions for decryption of received messages, but in that case it SHOULD indicate the untrusted nature of such messages to the user. This rule does not apply to empty OMEMO messages (as per Sending a message) that are used purely to transfer key material, e.g. as part of heartbeat messages or automatic key exchange completion.
+When prompting the user for a trust decision regarding a key, the client SHOULD present the user with a fingerprint in the form of a hex-string, QR code, or other unique representation, such that it can be compared by the user. To ensure interoperability between clients and older versions of OMEMO, the fingerprint SHOULD be chosen to be the public part of the IdentityKey in its byte-encoded Curve25519 form (see the notes on XEdDSA and the byte-encoding of public keys in the X3DH protocol section for details). When displaying the fingerprint as a hex-string, the RECOMMENDED way to make it easier to compare the fingerprint is to split the lowercase hex-string into 8 substrings of 8 chars each, then coloring each group of 8 lowercase hex chars using &xep0392;.
+Clients MUST NOT react to decryption errors by initiating new sessions automatically and without user interaction. An exception to this rule is specified for clients that support automatic session healing as per XEP-XXXX. TODO: Refer to the omemo-session-healing XEP as soon as it is accepted.
While it is RECOMMENDED that clients postpone private key deletion until after message catch-up, the X3DH standard mandates that clients should not use duplicate-PreKey sessions for sending, so clients MAY delete such keys immediately for security reasons. For additional information on potential security impacts of this decision, refer to
First draft based on XEP-0423.
++ There is a growing number of XMPP Extension Protocols (XEPs) that provide + different building blocks for XMPP-based applications. XMPP software + developers are confronted with the challenge of finding the right + combination of XEPs for a given application profile. Users need a way to + compare applications without resorting to comparing for individual XEP + numbers. +
++ This document defines XMPP application Categories based on + typical use cases (Core, Web, IM, Mobile) and Levels + (Core, Advanced) based on functionality in the respective category. For + each combination of those, the required XEPs are referenced. As the + protocol landscape changes over time, this document is updated roughly + once a year. +
++ For developers, this document provides guidance on which specifications + they need to consider when implementing an application of a certain kind. + By completing a compliance test or performing a self-assessment, they can + advertise their implementation as compliant with a given Category and + Level. +
++ For users, this provides an easy way to compare implementations based on + their respective advertised compliance levels and year. +
++ Unless explicitly noted, support for the listed specifications is REQUIRED + for compliance purposes. + A feature is considered supported if all comma separated feature providers + listed in the "Providers" column are implemented (unless otherwise noted). +
+The following changes were made to the Compliance Suites since &xep0423;:
+The following changes were made to the Compliance Suites since &xep0412;:
+| Feature | +Core Server | +Core Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Core features | +&yes; | +&yes; | +&yes; | +&yes; | +&rfc6120; |
+
| TLS | +&yes; | +&yes; | +&yes; | +&yes; | +&rfc7590; | +
| Direct TLS | +&no; | +&no; | +&yes; |
+ &yes; | +&xep0368; | +
| Feature discovery | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0030; | +
| Feature broadcasts | +&no; | +&yes; | +&yes; | +&yes; | +&xep0115; | +
| Server Extensibility | +&yes; | +N/A | +&yes; | +N/A | +&xep0114; | +
| Event publishing | +&no; | +&no; | +&yes;&pubsubjid; | +&yes; | +&xep0163; | +
+ To be considered XMPP web compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Core Server | +Core Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Web Connection Mechanisms | +&yes;&component; | +&yes;&onlyone; | +&yes;&component; | +&yes;&onlyone; | +&rfc7395;, &xep0206; (See also: &xep0124;) | +
| Connection Mechanism Discovery | +&no; | +&no; | +N/A | +&yes; | +&xep0156; | +
+ To be considered XMPP IM compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Core Server | +Core Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Core features | +&yes; | +&yes; | +&yes; | +&yes; | +&rfc6121; | +
| The /me Command | +N/A | +&yes; | +N/A | +&yes; | +&xep0245; | +
| User Avatars | +N/A | +&no; | +N/A | +&yes;&nocli; | +&xep0084; | +
| User Avatar Compatibility | +&no; | +&no; | +&yes; | +&yes;&nocli; | +&xep0398;, &xep0153; | +
| vcard-temp | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0054; | +
| Outbound Message Synchronization | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0280; | +
| User Blocking | +&no; | +&no; | +&yes; | +&yes; | +&xep0191; | +
| Group Chat | +&yes;&component; | +&yes;&usecases; | +&yes;&component; | +&yes;&usecases; | +&xep0045; |
+
| Advanced Group Chat | +&no; | +&no; | +&yes;&component; | +&yes; | +&xep0048;, &xep0313; |
+
| Persistent Storage of Private Data via PubSub | +&no; | +&no; | +&yes;&component; | +&yes; | +&xep0223; | +
| Private XML Storage | +&no; | +&no; | +&yes;&component; | +&yes; | +&xep0049; (only recommended for legacy bookmarks support) | +
| Stream Management | +&no; | +&no; | +&yes; | +&yes; | +&xep0198; | +
| Message Acknowledgements | +N/A | +&no; | +N/A | +&yes; | +&xep0184; | +
| History Storage / Retrieval | +&no; | +&no; | +&yes; | +&yes; | +&xep0313; | +
| Chat States | +N/A | +&no; | +N/A | +&yes; | +&xep0085; | +
| Message Correction | +N/A | +&no; | +N/A | +&yes; | +&xep0308; | +
| File Upload | +&yes;&component; | +&yes; | +&yes;&component; | +&yes; | +&xep0363; | +
| Direct File Transfer | +N/A | +&no; | +N/A | +&yes; | +&xep0234;, &xep0261; | +
+ Further specifications of note, which are not required for compliance: +
++ To be considered XMPP mobile compliant, all features from the core + compliance category must be met, as well as all features in this suite. +
+| Feature | +Core Server | +Core Client | +Advanced Server | +Advanced Client | +Providers | +
|---|---|---|---|---|---|
| Stream Management | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0198; | +
| Client State Indication | +&yes; | +&yes; | +&yes; | +&yes; | +&xep0352; | +
| Third Party Push Notifications | +&no; | +&no; | +&yes;&component; | +&yes; |
+ &xep0357; | +
+ Further specifications of note, which are not required for compliance: +
+This section outlines the protocol specifications that are relevant for + developers, but are not ready yet to be required for Compliance. + Developers are encouraged to implement those and + to share their experience and feedback.
++ Some of the protocol specifications referenced herein have their own + dependencies; developers need to consult the relevant specifications for + further information. +
++ This document introduces no additional security considerations above and + beyond those defined in the documents on which it depends. +
+This document requires no interaction with &IANA;.
+This document requires no interaction with the ®ISTRAR;.
++ The author would like to thank Guus der Kinderen, Dele Olajide, Marc + Laporte, Dave Cridland, Daniel Gultsch, Florian Schmaus, Tobias Markmann, + and Jonas Schäfer for their suggestions. +
+