moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Merge branch 'xep-0384' into premerge

Browse Source
This commit is contained in:
Jonas Schäfer 2021-09-28 22:10:20 +02:00
commit fa100637df
1 changed files with 32 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

48
xep-0384.xml
View File

@ -1,9 +1,9 @@
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [ <!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY content "&lt;content/&gt;"> <!ENTITY envelope "&lt;envelope/&gt;">
<!ENTITY payload "&lt;payload/&gt;"> <!ENTITY payload "&lt;payload/&gt;">
<!ENTITY % ents SYSTEM "xep.ent"> <!ENTITY % ents SYSTEM "xep.ent">
<!ENTITY ns "urn:xmpp:omemo:1"> <!ENTITY ns "urn:xmpp:omemo:2">
<!ENTITY nsdevices "urn:xmpp:omemo:1:devices"> <!ENTITY nsdevices "urn:xmpp:omemo:1:devices">
<!ENTITY nsbundles "urn:xmpp:omemo:1:bundles"> <!ENTITY nsbundles "urn:xmpp:omemo:1:bundles">
%ents; %ents;
@ -57,6 +57,20 @@
<email>xmpp@larma.de</email> <email>xmpp@larma.de</email>
<jid>jabber@larma.de</jid> <jid>jabber@larma.de</jid>
</author> </author>
<revision>
<version>0.8.0</version>
<date>2021-09-28</date>
<initials>melvo</initials>
<remark>
<p>Update to XEP-0420 version 0.4.0 and adjust namespace:</p>
<ul>
<li>Replace SCE's old 'content' element by its new 'envelope' element</li>
<li>Replace SCE's old 'payload' element by its new 'content' element</li>
<li>Update SCE's namespace to 'urn:xmpp:sce:1'</li>
<li>Update namespace to 'urn:xmpp:omemo:2'</li>
</ul>
</remark>
</revision>
<revision> <revision>
<version>0.7.0</version> <version>0.7.0</version>
<date>2020-09-05</date> <date>2020-09-05</date>
@ -98,7 +112,7 @@
<li>Specify OMEMO encryption for XEP-0045 Multi-User Chats.</li> <li>Specify OMEMO encryption for XEP-0045 Multi-User Chats.</li>
<li>Use XEP-0420: Stanza Content Encryption.</li> <li>Use XEP-0420: Stanza Content Encryption.</li>
<li>Use AES256/CBC to encrypt SCE payload.</li> <li>Use AES256/CBC to encrypt SCE payload.</li>
<li>Change namespace to <tt>&ns;</tt></li> <li>Change namespace to <tt>urn:xmpp:omemo:1</tt></li>
<li>Use wrapping 'keys' element for key elements in 'header'.</li> <li>Use wrapping 'keys' element for key elements in 'header'.</li>
<li>Define threat model</li> <li>Define threat model</li>
<li>Change the state back to Experimental</li> <li>Change the state back to Experimental</li>
@ -495,12 +509,12 @@
<p> <p>
In order to send a message, extension elements that are deemed sensible first have to be In order to send a message, extension elements that are deemed sensible first have to be
encrypted. For this purpose, extensions that are only intended to be accessible to the recipient encrypted. For this purpose, extensions that are only intended to be accessible to the recipient
are placed inside a &xep0420; &content; element, which is then encrypted using a message key. are placed inside a &xep0420; &envelope; element, which is then encrypted using a message key.
For this reason OMEMO defines its own SCE profile. For this reason OMEMO defines its own SCE profile.
</p> </p>
<section3 topic='SCE Profile' anchor='sce'> <section3 topic='SCE Profile' anchor='sce'>
<p> <p>
An OMEMO SCE &content; element An OMEMO SCE &envelope; element
</p> </p>
<ul> <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>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>
@ -508,21 +522,21 @@
<li>SHOULD contain a &lt;from/&gt; affix element.</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> <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> </ul>
<example caption='Plaintext SCE content element'><![CDATA[ <example caption='Plaintext SCE envelope element'><![CDATA[
<content xmlns='urn:xmpp:sce:0'> <envelope xmlns='urn:xmpp:sce:1'>
<payload> <content>
<body xmlns='jabber:client'> <body xmlns='jabber:client'>
Hello World! Hello World!
</body> </body>
</payload> </content>
<rpad>...</rpad> <rpad>...</rpad>
<from jid='romeo@montague.lit'/> <from jid='romeo@montague.lit'/>
</content>]]> </envelope>]]>
</example> </example>
</section3> </section3>
<section3 topic='Encryption' anchor='encrypt'> <section3 topic='Encryption' anchor='encrypt'>
<p> <p>
The &content; element is encrypted as described in the section about <link url='#protocol-message_encryption'>Message Encryption</link>. The &envelope; element is encrypted as described in the section about <link url='#protocol-message_encryption'>Message Encryption</link>.
</p> </p>
<p> <p>
Clients MUST only consider the devices on the <tt>&nsdevices;</tt> node of each recipient (i.e. including their own devices node, but excluding itself). Clients MUST only consider the devices on the <tt>&nsdevices;</tt> node of each recipient (i.e. including their own devices node, but excluding itself).
@ -533,7 +547,7 @@
An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It contains up to two child nodes, the &lt;header&gt; and the &payload; element. The &lt;header&gt; element must always be present, the &payload; element must be present unless an empty OMEMO message is sent, as described below. An OMEMO encrypted message is specified to include an &lt;encrypted&gt; element in the <tt>&ns;</tt> namespace. It contains up to two child nodes, the &lt;header&gt; and the &payload; element. The &lt;header&gt; element must always be present, the &payload; element must be present unless an empty OMEMO message is sent, as described below.
The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs, as well as one or multiple &lt;key&gt; elements. The &lt;header&gt; element has an attribute named 'sid' referencing the device id of the sending device and contains one or multiple &lt;keys&gt; elements, each with an attribute 'jid' of one of the recipients bare JIDs, as well as one or multiple &lt;key&gt; elements.
A &lt;key&gt; 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 &lt;key&gt; element. A &lt;key&gt; 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 &lt;key&gt; element.
The encrypted &content; element is encoded using base64 and placed as text content into the &payload; element. The encrypted &envelope; element is encoded using base64 and placed as text content into the &payload; element.
</p> </p>
<!-- TODO: <p>Note that following &rfc6120; (section 8.4.), clients MUST ignore XML attributes and elements that are qualified with an unknown namespace, in order to allow for protocol extensions.</p> (qualified attributes are evil, right?) --> <!-- TODO: <p>Note that following &rfc6120; (section 8.4.), clients MUST ignore XML attributes and elements that are qualified with an unknown namespace, in order to allow for protocol extensions.</p> (qualified attributes are evil, right?) -->
<p>A special case are <em>empty</em> 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 &lt;key&gt; elements as usual, but the &payload; element is omitted altogether, so that the &lt;encrypted&gt; element only contains a &lt;header&gt;.</p> <p>A special case are <em>empty</em> 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 &lt;key&gt; elements as usual, but the &payload; element is omitted altogether, so that the &lt;encrypted&gt; element only contains a &lt;header&gt;.</p>
@ -551,7 +565,7 @@
</keys> </keys>
</header> </header>
<payload> <payload>
base64/encoded/message/key/encrypted/content/element base64/encoded/message/key/encrypted/envelope/element
</payload> </payload>
</encrypted> </encrypted>
<store xmlns='urn:xmpp:hints'/> <store xmlns='urn:xmpp:hints'/>
@ -579,16 +593,16 @@
Any existing double ratchet sessions SHOULD remain intact. At any point any party MAY Any existing double ratchet sessions SHOULD remain intact. At any point any party MAY
revert their decision and go back to sending OMEMO encrypted messages again.</p> revert their decision and go back to sending OMEMO encrypted messages again.</p>
<example caption='A client signaling that it’s account no longer wants to receive OMEMO-encrypted messages'><![CDATA[ <example caption='A client signaling that it’s account no longer wants to receive OMEMO-encrypted messages'><![CDATA[
<content xmlns='urn:xmpp:sce:0'> <envelope xmlns='urn:xmpp:sce:1'>
<payload> <content>
<opt-out xmlns=']]>&ns;<![CDATA['> <opt-out xmlns=']]>&ns;<![CDATA['>
<reason> <reason>
Sorry, but for compliance reasons I need a permanent, Sorry, but for compliance reasons I need a permanent,
server-side, record of our conversation. server-side, record of our conversation.
</reason> </reason>
</opt-out> </opt-out>
</payload>
</content> </content>
</envelope>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Group Chats' anchor='group-chats'> <section2 topic='Group Chats' anchor='group-chats'>
@ -647,7 +661,7 @@
</keys> </keys>
</header> </header>
<payload> <payload>
base64/encoded/message/key/encrypted/content/element base64/encoded/message/key/encrypted/envelope/element
</payload> </payload>
</encrypted> </encrypted>
<store xmlns='urn:xmpp:hints'/> <store xmlns='urn:xmpp:hints'/>