From 8b02d0e79aacbe19fd82854893f52d76083b72dd Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Thu, 5 Nov 2020 19:34:22 +0100 Subject: [PATCH 1/2] XEP-0384: Release version 0.8.0 Update to XEP-0420 version 0.4.0 and adjust namespace: * Replace SCE's old 'content' element by its new 'envelope' element * Replace SCE's old 'payload' element by its new 'content' element * Update SCE's namespace to 'urn:xmpp:sce:1' * Update namespace to 'urn:xmpp:omemo:2' --- xep-0384.xml | 50 ++++++++++++++++++++++++++++++++------------------ 1 file changed, 32 insertions(+), 18 deletions(-) diff --git a/xep-0384.xml b/xep-0384.xml index ce0739b6..f797a385 100644 --- a/xep-0384.xml +++ b/xep-0384.xml @@ -1,9 +1,9 @@ + - + %ents; @@ -57,6 +57,20 @@ xmpp@larma.de jabber@larma.de + + 0.8.0 + 2020-11-05 + melvo + +

Update to XEP-0420 version 0.4.0 and adjust namespace:

+
    +
  • Replace SCE's old 'content' element by its new 'envelope' element
    • +
  • Replace SCE's old 'payload' element by its new 'content' element
    • +
  • Update SCE's namespace to 'urn:xmpp:sce:1'
    • +
  • Update namespace to 'urn:xmpp:omemo:2'
    • +
+ + 0.7.0 2020-09-05 @@ -98,7 +112,7 @@
  • Specify OMEMO encryption for XEP-0045 Multi-User Chats.
  • Use XEP-0420: Stanza Content Encryption.
  • Use AES256/CBC to encrypt SCE payload.
    • -
  • Change namespace to &ns;
    • +
  • Change namespace to urn:xmpp:omemo:1
  • Use wrapping 'keys' element for key elements in 'header'.
  • Define threat model
  • Change the state back to Experimental
    • @@ -495,12 +509,12 @@

    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 - 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.

    - An OMEMO SCE &content; element + An OMEMO SCE &envelope; element

    • MUST contain an <rpad/> 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.
      • @@ -508,21 +522,21 @@
    • SHOULD contain a <from/> affix element.
    • MUST contain a <to/> 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.
    - - + + Hello World! - + ... -]]> +]]>

    - The &content; element is encrypted as described in the section about Message Encryption. + The &envelope; element is encrypted as described in the section about Message Encryption.

    Clients MUST only consider the devices on the &nsdevices; 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 <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. + The encrypted &envelope; 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>.

    @@ -551,7 +565,7 @@ - base64/encoded/message/key/encrypted/content/element + base64/encoded/message/key/encrypted/envelope/element @@ -579,16 +593,16 @@ 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.

    - + + Sorry, but for compliance reasons I need a permanent, server-side, record of our conversation. - - + + ]]> @@ -647,7 +661,7 @@ - base64/encoded/message/key/encrypted/content/element + base64/encoded/message/key/encrypted/envelope/element From fb4de0db48a29f1fe0f276298575ffb4b52cc4ac Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= Date: Tue, 28 Sep 2021 22:10:09 +0200 Subject: [PATCH 2/2] XEP-0384: fix date --- xep-0384.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0384.xml b/xep-0384.xml index f797a385..72ed4b40 100644 --- a/xep-0384.xml +++ b/xep-0384.xml @@ -59,7 +59,7 @@ 0.8.0 - 2020-11-05 + 2021-09-28 melvo

    Update to XEP-0420 version 0.4.0 and adjust namespace: