<abstract>The Stanza Content Encryption (SCE) protocol is intended as a way to allow clients to securely exchange arbitrary extension elements using different end-to-end encryption schemes.</abstract>
<remark>Accepted by vote of Council on 2019-06-26.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2019-06-03</date>
<initials>ps</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>There is a number of different end-to-end encryption mechanisms that can be used to secure user communication against unauthorized access from malicious third parties. Popular examples for this are &xep0384; and &xep0373;.</p>
<p>While the latter allows for encryption of arbitrary extension elements, protocols such as &xep0384; are limited to only encrypt the body of a message. This approach is not very flexible and prevents the combined usage with XMPP extension protocols such as &xep0385; or &xep0308; as their extension elements cannot be included in the encrypted part of the message, therefore leaking information about the message content.</p>
<p>This extension protocol proposes a solution to aforementioned issues by generalizing the OpenPGP Content Elements (eg. <linkurl="https://xmpp.org/extensions/xep-0373.html#example-2"><signcrypt></link>) introduced by &xep0373; for the use with other encryption protocols.</p>
<p>This proposal widens the scope of the security guarantees given by the used encryption mechanism from just the body of the message to various extension elements. It is intended to serve as a "one size fits all" solution for extension element encryption in XMPP.</p>
<td>Prevent known ciphertext and message length correlation attacks. The content of this element is a randomly generated sequence of random length between 0 and 200 characters. TODO: sane boundaries?</td>
<td>Prevent replay attacks using old messages. This element MUST have one attribute 'stamp', whose value is a timestamp following the format described in &xep0082;. The timestamp represents the time at which the message was encrypted by the sender.</td>
<td>Receiving clients MUST check whether the difference between the timestamp and the sending time derived from the stanza itself lays within a reasonable margin. The client SHOULD use the content of the timestamp element when displaying the send date of the message</td>
<p>Encryption protocols that make use of Stanza Content Encryption MUST define their own profiles that describe mandatory behaviour of which of these elements are used. They MAY also define and add their own specific affix elements.</p>
<p>Some end-to-end encryption protocols like &xep0384; are historically limited to encryption of the message body only. This approach excludes other extension elements from the protected domain of the payload element, exposing them to potential attackers.</p>
<examplecaption='An imperfectly encrypted message which leaks dangerous information about the conversation through the plaintext OOB extension element'><