Add SCE usage and remove some Signal references

xep-0384.xml

@@ -1,5 +1,7 @@
 <?xml version='1.0' encoding='UTF-8'?>
 <!DOCTYPE xep SYSTEM 'xep.dtd' [
+  <!ENTITY content "&lt;content/&gt;">
+  <!ENTITY payload "&lt;payload/&gt;">
   <!ENTITY % ents SYSTEM "xep.ent">
 %ents;
 ]>
@@ -90,21 +92,18 @@
       external complexity.
     </p>
     <p>
-      This XEP defines a protocol that leverages the SignalProtocol encryption to provide
+      This XEP defines a protocol that leverages the Double Ratchet Algorithm to provide
       multi-end to multi-end encryption, allowing messages to be synchronized
-      securely across multiple clients, even if some of them are offline. The SignalProtocol
+      securely across multiple clients, even if some of them are offline.
-      is a cryptographic double ratched protocol based on work by Trevor Perrin
+      The Double Ratched protocol is based on work by Trevor Perrin
-      and Moxie Marlinspike first published as the Axolotl protocol. While the
+      and Moxie Marlinspike and was first published as the Axolotl protocol.
-      protocol itself has specifications in the public domain, the
+      The specification for the protocol is available in the public domain.
-      protobuf-based wire format of the signal protocol is not fully
-      documented. The signal protocol currently only exists in GPLv3-licensed
-      implementations maintained by OpenWhisperSystems.
     </p>
   </section2>
   <section2 topic='Overview' anchor='intro-overview'>
     <p>
       The general idea behind this protocol is to maintain separate,
-      long-standing SignalProtocol-encrypted sessions with each device of each contact
+      long-standing Double Ratchet-encrypted sessions with each device of each contact
       (as well as with each of our other devices), which are used as secure key
       transport channels. In this scheme, each message is encrypted with a
       fresh, randomly generated encryption key. An encrypted header is added to
@@ -125,8 +124,9 @@
       of inter-client history synchronization is achieved.
     </p>
     <p>
-      OMEMO currently uses version 3 SignalProtocol. Instead of a Signal key
+      While in the future a dedicated key server component could be used to distribute
-      server, &xep0163; (PEP) is used to publish key data.
+      key material for session creation, the current specification relies on PEP to publish
+      and acquire key bundles.
     </p>
   </section2>
 </section1>
@@ -376,19 +376,36 @@
   </section2>
   <section2 topic='Sending a message' anchor='usecases-messagesend'>
     <p>
-      In order to send a chat message, its &lt;body&gt; first has to be
+      In order to send a chat message, extension elements that are deemed sensible first have to be
-      encrypted. The client MUST use fresh, randomly generated key with
+      encrypted. For this purpose, extensions that are only intended to be accessible to the recipient
-      AES-256..
+      are placed inside a &xep0420; &content; element, which is then encrypted using a message key.
-      The 16 bytes key and the GCM authentication tag (The tag SHOULD have at least
+      For this reason OMEMO defines its own SCE profile.
-      128 bit) are concatenated and for each intended recipient device,
-      i.e. both own devices as well as devices associated with the contact, the
-      result of this concatenation is encrypted using the corresponding
-      long-standing SignalProtocol session. Each encrypted payload key/authentication tag
-      tuple is tagged with the recipient device's ID. The key element MUST be
-      tagged with a prekey attribute set to true if a PreKeySignalMessage is being
-      used. This is all serialized into a MessageElement, which is transmitted
-      in a &lt;message&gt; as follows:
     </p>
+    <section3 topic='SCE Profile' anchor='sce'>
+      <p>
+        An OMEMO SCE &content; element
+      </p>
+      <ul>
+        <li>MUST contain an &lt;rpad/&gt; affix element. This is used to prevent an attacker from gaining insights about the content of a message based on the length of the ciphertext.</li>
+        <li>MAY contain a &lt;time/&gt; affix element. This can be used to prevent the server from modifying the order in which messages from different sending devices have been sent.</li>
+        <li>SHOULD contain a &lt;from/&gt; affix element.</li>
+        <li>MUST contain a &lt;to/&gt; affix element whenever a message is sent via a group chat (MUC/MIX). This is used to prevent the server from silently converting a group message into a private message and vice versa.</li>
+      </ul>
+    </section3>
+    <p>
+      The ciphertext that is the encrypted &content; element is then encoded using base64 and placed as text content into the &payload; element.
+    </p>
+    <example caption="Plaintext SCE content element"><![CDATA[
+<content xmlns='urn:xmpp:sce:0'>
+  <payload>
+    <body xmlns='jabber:client'>
+     Hello World!
+    </body>
+  </payload>
+  <rpad>...</rpad>
+  <from jid='romeo@montague.lit'/>
+</content>]]>
+    </example>
     <example caption="Sending a message"><![CDATA[
 <message to='juliet@capulet.lit' from='romeo@montague.lit' id='send1'>
   <encrypted xmlns='urn:xmpp:omemo:1'>
@@ -402,7 +419,9 @@
         <!-- ... -->
       </keys>
     </header>
-    <payload>BASE64ENCODED</payload>
+    <payload>
+      -- MESSAGE-KEY-ENCRYPTED CONTENT ELEMENT --
+    </payload>
   </encrypted>
   <store xmlns='urn:xmpp:hints'/>
 </message>]]></example>