moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0384: rephrase 'session termination' to 'opting-out' 

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)
This commit is contained in:
Daniel Gultsch 2020-03-09 08:31:43 +01:00
parent 22a6085cac
commit 9ecaa1ee73
1 changed files with 25 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
xep-0384.xml
View File

@ -442,15 +442,6 @@
</iq>]]></example>
<p>A random pk entry is selected, and used to build an OMEMO session.</p>
</section2>
<section2 topic='Ending a session' anchor='usecases-ending'>
<p>In order to signal a contact that you like to terminate a session, your
device MUST send a &lt;terminate&gt; 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 &lt;terminate&gt; 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.</p>
</section2>
<section2 topic='Sending a message' anchor='usecases-messagesend'>
<p>
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 <link url="#protocol-message_decryption">Message Decryption</link>.
</p>
</section2>
<section2 topic='Opt-out' anchor='opt-out'>
<p>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 &lt;opt-out/&gt; element qualified
by the <tt>&ns;</tt> namespace to all intended recipient devices
inside an encrypted stanza. The element MAY contain a child element &lt;reason&gt;.
If a device is receiving an encrypted stanza containing an &lt;opt-out/&gt; 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.</p>
<example caption='A client signaling that it’s account no longer wants to receive OMEMO-encrypted messages'><![CDATA[
<content xmlns='urn:xmpp:sce:0'>
<payload>
<opt-out xmlns=']]>&ns;<![CDATA['>
<reason>
Sorry, but for compliance reasons I need a permanent,
server-side, record of our conversation.
</reason>
</opt-out>
</payload>
</content>
]]></example>
</section2>
<section2 topic='Group Chats' anchor='group-chats'>
<p>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;.</p>
<p>A Multi-User Chat room that supports OMEMO MUST be configured non-anonymous and SHOULD be configured members-only.</p>