XEP-xxxx: Ephemeral Messages

Abstract
This specification defines a protocol to send ephemeral messages over XMPP and synchronize timer value setting across devices.
Author
Alexander Krotov
Copyright
© 1999 – 2020 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

ProtoXEP

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Type
Standards Track
Version
0.0.1 (2018-04-10)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Draft
  4. Final

1. Introduction

Existing protocols deployed in XMPP networks offer forward secrecy both on the transport (TLS) and message (Current Jabber OpenPGP Usage (XEP-0027) [1] and OMEMO Encryption (XEP-0384) [2]) levels. Forward secrecy prevents recorded communications from being decrypted even if long term encryption keys are compromised by generating ephemeral keys and securely deleting them when they are no longer needed.

However, even though keys are deleted, message contents is retained both in server and client archives. While servers can be instructed with message hints (Message Processing Hints (XEP-0334) [3]) not to store some messages in the archives (Message Archive Management (XEP-0313) [4]) or prevented from saving them in plain text by the use of end-to-end encryption, most XMPP clients still retain message content almost indefinitely. A device with an installed XMPP client that can be lost or stolen becomes the weakest link.

Unlike ephemeral keys, which have specified lifetimes, message contents cannot be removed immediately after being read. Users have to decide for how long they want to retain conversation contents. Verbally agreeing on the time interval and manually removing messages from all devices is cumbersome and error-prone.

This XEP defines a way to attach a timer value to messages which in order to specify for how long XMPP clients should store message contents. Besides that, it defines a way to synchronize common timer setting across all users of the conversation.

The specification does not depend on any encryption scheme and does not require encryption at all. It can be used with plaintext messages as long as users trust their servers to respect Message Processing Hints (XEP-0334) [3].

Other IM systems, such as Signal, Wickr, Wire and Telegram, already offer ephemeral messages. Signal offers timer synchronization feature for user groups and Telegram offers it for secret chats, which are limited to two users.

2. Requirements

3. Glossary

Explicit timer update
A message with an empty ephemeral tag, sent to update timer setting on all devices participating in a chat.
Implicit timer update
A message with a non-empty ephemeral tag, treated as a timer update for the puprose of timer setting synchronization.

4. Use Cases

4.1 Determining Support

If an entity supports ephemeral messages, it MUST advertise that fact in its responses to Service Discovery (XEP-0030) [5] information (disco#info requests by returning a feature of urn:xmpp:ephemeral:0.

Example 1. A disco#info Query
<iq from='romeo@shakespeare.lit/orchard'
    id='disco1'
    to='juliet@capulet.com/balcony'
    type='get'>
    <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
Example 2. A disco#info Response
<iq from='juliet@capulet.com/balcony'
    id='disco1'
    to='romeo@shakespeare.lit/orchard'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <feature var='urn:xmpp:ephemeral:0'/>
  </query>
</iq>

An XMPP client SHOULD warn the user if not all recipients support ephemeral messages.

To avoid downgrade attack, an XMPP client MUST allow the user to force sending of ephemeral message even if no recipient has indicated support for them.

4.2 Sending a Plaintext Ephemeral Message

To send an ephemeral message, an XMPP client places message contents into <ephemeral> tag with a <timer> attribute set to the number of seconds after which the message contents is to be securely deleted from the recipient device. XMPP client MUST include a <no-permanent-store/> hint (see Message Processing Hints (XEP-0334) [3]), as any permanent storage of ephemeral message defeats its purpose.

Here is an example of sending a plaintext ephemeral message with a 24 hours (86400 seconds) timer value.

Example 3. A Plaintext Ephemeral Message
<message from='romeo@montague.net/orchard'
    to='juliet@capulet.com'>
  <ephemeral xmlns='urn:xmpp:ephemeral:0' timer='86400'>
    <body>
      TODO insert some message text
    </body>
  </ephemeral>
  <body>
    This is an ephemeral message.
  </body>
  <no-permanent-store xmlns="urn:xmpp:hints"/>
</message>

4.3 Sending a Timer Setting Update

When user manually changes ephemeral message timer setting in an XMPP client, XMPP client SHOULD send an ephemeral message timer update.

Timer update message SHOULD be sent immediately. An XMPP client MAY choose to postpone sending a timer update, remember the current value and ignore implicit timer updates until either the user sends a message or an explicit timer update is received. It may be useful, for example, to avoid waking up wireless connection when user device has low battery.

A timer update is simply an ephemeral message without a body. However, for timer setting updates XMPP client SHOULD use <store> hint, to ensure that timer setting is updated properly on offline clients when they go online.

Example 4. An Ephemeral Message Timer Update
<message from='romeo@montague.net/orchard'
    to='juliet@capulet.com'>
  <ephemeral xmlns='urn:xmpp:ephemeral:0' timer='86400'/>
  <store xmlns="urn:xmpp:hints"/>
</message>

4.4 Receiving Ephemeral Messages

An XMPP client receiving an message with an <ephemeral> tag SHOULD update the timer setting to the value of timer attribute. It MAY ignore implicit timer updates if it has postponed sending a timer update message, as described in Sending a Timer Setting Update section.

The rationale for updating the timer value upon receiving ephemeral messages with contents, in contrast to explicit ephemeral timer updates, is to make sure devices get synchronized eventually even if timer updates are lost. It may happen, for example, if some device stays offline longer than the lifetime of offline message storage (see Best Practices for Handling Offline Messages (XEP-0160) [6]).

After that, client moves the contents of <ephemeral> into the <message> and ignores any elements outside the <ephemeral>, such as <body> element intended for legacy clients.

The resulting message is processed as usual.

4.5 Exchanging Ephemeral OMEMO Messages

OMEMO requires that messages are delivered in a sequence. If a message is missing, all the following messages cannot be decrypted and a new session has to be established. To prevent this kind of situation, additional steps are required to make sure ephemeral messages are not sent to clients that will ignore them because they do not support them.

4.5.1 Announcing Support for Ephemeral Messages

An OMEMO-capable device implementing ephemeral messages MUST indicate support for ephemeral messages in its Bundle (see OMEMO Encryption (XEP-0384) [2]).

Example 5. Announcing Ephemeral Message Support
<iq from='juliet@capulet.lit' type='set' id='announce'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='eu.siacs.conversations.axolotl.bundles:12345'>
      <item>
        <bundle xmlns='eu.siacs.conversations.axolotl'>
          <!-- XEP-0384 elements here ... -->
          <ephemeral xmlns='urn:xmpp:ephemeral:0'/>
        </bundle>
      </item>
    </publish>
  </pubsub>
</iq>

4.5.2 Sending an Ephemeral Message

When sending an ephemeral OMEMO message, XMPP client MUST NOT encrypt it for clients that did not indicate support for ephemeral messages explicitly.

4.6 Exchanging Encrypted Ephemeral Messages

While OMEMO in its current revision allows only the body to be encrypted, some other encryption schemes, such as OpenPGP for XMPP Instant Messaging (XEP-0374) [7] allow to encrypt the <ephemeral> tag itself.

If such a scheme is used, an XMPP client SHOULD encrypt <ephemeral> tag instead of placing encrypted message into it.

5. Timer Management

Sender device MUST start the timer immediately after sending it, if Stream Management is not used (Stream Management (XEP-0198) [8]) or after receiving acknowledgement for <message> stanza, if Stream Management is available. This rule prevents the message from being deleted before it is successfully delivered to the server.

Device receiving a Message Carbons (XEP-0280) [9] carbon copy MUST start the timer immediately.

Messages received from other JID MUST be stored in the database along with their timer value and timer SHOULD NOT start until the user reads a message. When the message is read by the user, for example by opening a chat window, an XMPP client starts a timer and MUST securely delete message contents from the device when the timer expires. An XMPP client SHOULD NOT display message contents outside the chat window, for example in system notifications. However, if it is displayed outside the chat window, for example when the last message for the contact is displayed in the roster window, an XMPP client MAY not start a timer until user explicitly opens the chat window.

5.1 Encrypted Ephemeral Messages

If encrypted ephemeral messages are used, timer setting may become unsynchronized for devices that can not decrypt ephemeral messages. For this reason, whenever user changes an encryption scheme, an XMPP client SHOULD send an send an explicit timer update.

6. Internationalization Considerations

XMPP client MAY translate the message "This is an ephemeral message." to other languages and include multiple <body> elements with different xml:lang attributes for legacy clients.

7. Security Considerations

Devices implementing this specification MUST securely delete messages. For example, if SQLite is used as a database, secure_delete pragma MUST be set to 1 explicitly.

An XMPP client MUST NOT let the message contents outside the application, even to display it in a system notification. It has led to privacy issues in existing IM software before.

Plaintext ephemeral messages should not be relied upon for privacy. Legacy clients may store messages as raw XML contents, including the <ephemeral> tag, in their databases. Messages may be sent to third parties accidentally, for example if one of the servers is configured to deliver message contents in push notifications (Push Notifications (XEP-0357) [10]).

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

9. XMPP Registrar Considerations

This specification defines the following XML namespaces:

Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar [11] shall add the foregoing namespace to the registry located at <https://xmpp.org/registrar/namespaces.html>, as described in Section 4 of XMPP Registrar Function (XEP-0053) [12].

10. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:ephemeral:0'
    xmlns='urn:xmpp:ephemeral:0'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='ephemeral' type='ephemeral'/>

  <!-- TOOD: finish XML schema after the XEP leaves the 'experimental' state. -->
</xs:schema>

11. Acknowledgements

Thanks to Paul Schaub for the feedback incorporated into this specification.


Appendices

Appendix A: Document Information

Series
XEP
Number
xxxx
Publisher
XMPP Standards Foundation
Status
ProtoXEP
Type
Standards Track
Version
0.0.1
Last Updated
2018-04-10
Approving Body
XMPP Council
Dependencies
XMPP Core, XEP-0334, XEP-0384
Supersedes
None
Superseded By
None
Short Name
NOT_YET_ASSIGNED

This document in other formats: XML  PDF

Appendix B: Author Information

Alexander Krotov
Email
ilabdsf@gmail.com

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0027: Current Jabber OpenPGP Usage <https://xmpp.org/extensions/xep-0027.html>.

2. XEP-0384: OMEMO Encryption <https://xmpp.org/extensions/xep-0384.html>.

3. XEP-0334: Message Processing Hints <https://xmpp.org/extensions/xep-0334.html>.

4. XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>.

5. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.

6. XEP-0160: Best Practices for Handling Offline Messages <https://xmpp.org/extensions/xep-0160.html>.

7. XEP-0374: OpenPGP for XMPP Instant Messaging <https://xmpp.org/extensions/xep-0374.html>.

8. XEP-0198: Stream Management <https://xmpp.org/extensions/xep-0198.html>.

9. XEP-0280: Message Carbons <https://xmpp.org/extensions/xep-0280.html>.

10. XEP-0357: Push Notifications <https://xmpp.org/extensions/xep-0357.html>.

11. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

12. XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

  1. Version 0.0.1 (2018-04-10)

    First draft.

    psa

END