From 9ecaa1ee733d4d3ce222680005462bab828fd45d Mon Sep 17 00:00:00 2001 From: Daniel Gultsch Date: Mon, 9 Mar 2020 08:31:43 +0100 Subject: [PATCH] XEP-0384: rephrase 'session termination' to 'opting-out' MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sessions are device-to-device relationships. When we talk about 'opting-out' we want to communicate a _preference_ for an entire account not just on specific device-to-device relationship. The actual double ratchet sessions will also remain intact. So it is not reversing what ever we did in 'Starting a session' but just switching back from omemo to plain. (When we currently do that manuelly we also wouldn’t touch the actual underlying sessions) I would like to note at this point that we don’t have a way of 'opting-in' either. Nowhere do we say that a client MUST use OMEMO if they discover that the other side has bundles. Therefor I find it strange that the opt-out was a MUST and i weakend it to SHOULD. (we don’t say that a client SHOULD start omemo when it discovers support either so I even find a SHOULD too strong) --- xep-0384.xml | 34 +++++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/xep-0384.xml b/xep-0384.xml index 5b893b1f..d6dde962 100644 --- a/xep-0384.xml +++ b/xep-0384.xml @@ -442,15 +442,6 @@ ]]>

A random pk entry is selected, and used to build an OMEMO session.

- -

In order to signal a contact that you like to terminate a session, your - device MUST send a <terminate> element to all intended recipient devices - inside an encrypted stanza. A user or client MAY tag the element with a - reason. If a device is receiving a stanza containing a <terminate> element, - it MUST show an information that the peer has ended the session. To prevent - that the user is accidentally sending plaintext messages, the client MUST - block all outgoing message until the user switched to plaintext.

-

In order to send a chat message, extension elements that are deemed sensible first have to be @@ -525,6 +516,31 @@ After either the OMEMOKeyExchange or the OMEMOAuthenticatedMessage is decrypted, the content is decrypted as described in the section about Message Decryption.

+ +

An account can signal to a peer that it wants to stop communicating using + OMEMO encrypted messages and would like to proceed in plain text instead. To do + that any of that account’s devices sends an <opt-out/> element qualified + by the &ns; namespace to all intended recipient devices + inside an encrypted stanza. The element MAY contain a child element <reason>. + If a device is receiving an encrypted stanza containing an <opt-out/> element, + it SHOULD display the information, that the peer would like to receive plain text messages. + To prevent that the user is accidentally sending plaintext messages, the client MUST + block all outgoing message until the user has confirmed the switch to plaintext. + 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. + + + + +]]> +

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.