%ents; ]>
Stanza Content Encryption 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. &LEGALNOTICE; 0420 Experimental Standards Track Standards Council XMPP Core XEP-0001 Etc. SCE &paulschaub; 0.3.1 2020-11-03 gh/@melvo

Fix misspelling of 'whose'

0.3.0 2020-07-03 ps

Allow origin-id elements, disallow stanza-id and extended stanza addressing elements inside the payload element

Clarify wording on stanza processed elements and improve XEP formatting

Remove limitation of random padding content to base64 characters alone

Chat messages MUST contain message processing store hint

Credit where credit is due

0.2.0 2019-10-04 ps

Specify IQ encryption

Add examples and addenda

0.1.0 2019-07-30 XEP Editor (jsc) Accepted by vote of Council on 2019-06-26. 0.0.1 2019-06-03 ps

First draft.

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

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.

This extension protocol proposes a solution to aforementioned issues by generalizing the OpenPGP Content Elements (eg. <signcrypt>) introduced by &xep0373; for the use with other encryption protocols.

This proposal widens the scope of the security guarantees given by the used encryption mechanism from just the body of the message to all contents of the &content; element. It is intended to serve as a "one size fits all" solution for extension element encryption in XMPP.

In order to achieve its goal, Stanza Content Encryption does the following:

Envelope Element &envelope;
An XMPP extension element which is used to hold the encrypted &content; element.
Content Element &content;
An element which is used to contain all of those extension elements that need to be encrypted. The XML representation of this element is encrypted and then embedded into the &envelope; element.

In order to prevent certain attacks, different affix elements MAY be added into the &content; element.

Element Description Usage Verification
&rpad; Random-length random-content padding 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? None. This element is only used to change the length of the ciphertext and doesn't need to be verified
&time; Timestamp 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. 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
&to; Recipient of the message Prevent spoofing of the recipient. This element MUST have one attribute 'jid', whose value is the JID of the intended recipient. Receiving clients MUST check, if the JID matches the to attribute of the enclosing stanza and otherwise alert the user/reject the message
&from; Sender of the message Prevent spoofing of the sender. This element MUST have one attribute 'jid', whose value is the JID of the sender of the message. Receiving clients MUST check, if the value matches the from attribute of the enclosing stanza and otherwise alert the user/reject the message
C1DHN9HK-9A25tSmwK4hU!Jji9%GKYK^syIlHJT9TnI4 ]]>

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.

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.

...
SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMsIHRoZXNlIGFyZSBi cnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdpdGggdGhhdC4gSSBh bSBlbmxpZ2h0ZW5lZC4=
https://en.wikipedia.org/wiki/Fight_Club#Plot ]]>

The example above obviously leaks information about the communication through the unencrypted OOB extension element.

Most end-to-end encryption mechanisms are also focussed solely on message content encryption and do not tackle <iq/> requests/replies at all. Stanza Content Encryption can be applied to those as well.

]]> iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J REFUGNO9zL0NglAAxPEfdLTs4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0 vr4MkhoXe0rZigAAAABJRU5ErkJggg== ]]>

The main use case of Stanza Content Encryption is the use of end-to-end encryption protocols in combination with extension protocols that store sensitive information in other places than the message body.

This applies to many extension elements that add additional information to <message/> stanzas, such as those of &xep0066;.

[...] https://en.wikipedia.org/wiki/Fight_Club#Plot ]]> PGNvbnRlbnQgeG1sbnM9J3Vybjp4bXBwOnNjZTowJz48cGF5bG9hZD48Ym9keSB4bWxucz0namFi YmVyOmNsaWVudCc+SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMs IHRoZXNlIGFyZSBicnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdp dGggdGhhdC4gSSBhbSBlbmxpZ2h0ZW5lZC48L2JvZHk+PHggeG1sbnM9J2phYmJlcjp4Om9vYic+ PHVybD5odHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9GaWdodF9DbHViI1Bsb3Q8L3VybD48 L3g+PC9wYXlsb2FkPjwvY29udGVudD4= ]]>

Stanza Content Encryption thrives not only to allow for rich content encryption in <message/> stanzas, but is also applicable to <iq/> queries. A resource might want to query sensitive information from another resource capable of Stanza Content Encryption.

]]> V2FpdCwgd2hhdD8gQXJlIHlvdSBzZXJpb3VzPyBEaWQgeW91IHJlYWxseSBqdXN0IGdyYWIgeW91 ciBmYXZvdXJpdGUgYmFzZTY0IGRlY29kZXIganVzdCB0byBjaGVjayB0aGlzIGRvY3VtZW50IGZv ciBoaWRkZW4gbWVzc2FnZXM/IFdoYXQgYXJlIHlvdSBzb21lIGtpbmQgb2YgbmVyZD8gU29tZSBn ZWVrIHdpdGggYSBiaW5hcnkgd3Jpc3Qgd2F0Y2g/ ]]> iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAMAAAC67D+PAAAAclBMVEUAAADYZArfaA9GIAoBAAGN QA3MXgniaAiEOgZMIATDXRXZZhHUZBHIXhDrbQ6sUQ7OYA2TRAubRwqMQQq7VQlKHgMAAAK5WRfJ YBOORBFoMBCwUQ/ycA6FPgvbZQpeKglNJQmrTQeOPgQyFwR6MwACAABRPE/oAAAAW0lEQVQI1xXI Rw6EMBTAUP8kJKENnaF37n9FQPLCekAgzklhgCwfrlNHEXhrvCsxaU/SwLGAFuIWZFpBERtKm9Xf JqH+vVWh4POqgHrsAtht095b+geYRSl57QHSPgP3+CwvAAAAAABJRU5ErkJggg== ]]> PGNvbnRlbnQgeG1sbnM9J3Vybjp4bXBwOnNjZTowJz4KICA8cGF5bG9hZD4KICAgIDxkYXRhIHht bG5zPSd1cm46eG1wcDpib2InCiAgICAgICAgY2lkPSdzaGExKzhmMzVmZWYxMTBmZmM1ZGYwOGQ1 NzlhNTAwODNmZjkzMDhmYjYyNDJAYm9iLnhtcHAub3JnJwogICAgICAgIG1heC1hZ2U9Jzg2NDAw JwogICAgICAgIHR5cGU9J2ltYWdlL3BuZyc+CiAgICBpVkJPUncwS0dnb0FBQUFOU1VoRVVnQUFB QW9BQUFBS0NBTUFBQUM2N0QrUEFBQUFjbEJNVkVVQUFBRFlaQXJmYUE5R0lBb0JBQUdOCiAgICBR QTNNWGduaWFBaUVPZ1pNSUFURFhSWFpaaEhVWkJISVhoRHJiUTZzVVE3T1lBMlRSQXViUndxTVFR cTdWUWxLSGdNQUFBSzVXUmZKCiAgICBZQk9PUkJGb01CQ3dVUS95Y0E2RlBndmJaUXBlS2dsTkpR bXJUUWVPUGdReUZ3UjZNd0FDQUFCUlBFL29BQUFBVzBsRVFWUUkxeFhJCiAgICBSdzZFTUJUQVVQ OGtKS0VObmFGMzduOUZRUExDZWtBZ3prbGhnQ3dmcmxOSEVYaHJ2Q3N4YVUvU3dMR0FGdUlXWkZw QkVSdEttOVhmCiAgICBKcUgrdlZXaDRQT3FnSHJzQXRodDA5NWIrZ2VZUlNsNTdRSFNQZ1AzK0N3 dkFBQUFBQUJKUlU1RXJrSmdnZz09CiAgICA8L2RhdGE+CiAgPC9wYXlsb2FkPgogIDxmcm9tIGpp ZD0nbGFkeW1hY2JldGhAc2hha2VzcGVhci5saXQvY2FzdGxlJy8+CiAgPHRvIGppZD0nZG9jdG9y QHNoYWtlc3BlYXJlLmxpdC9wZGEnLz4KPC9jb250ZW50Pgo= ]]>

In order to send an encrypted message without leaking extension elements the sender prepares the message by placing the sensitive extension elements inside a &payload; element inside a &content; element.

Depending on the encryption-specific SCE-profile, some affix elements are added as child elements of the &content; element.

The &content; element is then serialized into XML and encrypted using the SCE-specific profile of the encryption mechanism in place. The result is appended to the message.

Since the outer message element does not contain a <body/> element the sender appends an unencrypted <store/> hint as specified in &xep0334;.

The message can then be sent to the recipient.

The recipient of the message decrypts the content of the &envelope; element to retrieve the &content; element. Depending on the affix profiles specified by the used encryption protocol, the affix elements are verified to prevent certain attacks from taking place.

Next the extension elements of the &content; elements &payload; element are checked against the whitelist/blacklist and any disallowed elements are discarded.

As a last step, the original unencrypted stanza is recreated by replacing the &envelope; element of the stanza with the contents of the &payload; element.

There are certain extension elements which are required to be available to the server in order to do message routing and processing. Additionally there are some elements that MUST be filtered by the server. Allowing for those elements to be included in, and parsed from the encrypted payload would allow a malicious client to perform a number of attacks.

Contrary to this, other elements are considered sensitive and MUST NOT be available in plaintext outside the &content; element.

It is hard to come up with a complete list of exceptional elements at this point, as there is no practical implementation experience.

Below is a non-exhaustive list of elements that are definitely blacklisted inside the &content; element and whitelisted as direct child elements of the message.

Element Reason
Elements of &xep0334; Message Processing Hints are addressed to the server and MUST therefore be accessible in plaintext. A receiving client MUST ignore any message processing hints encountered inside the encrypted &content; element
Stanza-ID elements of &xep0359; Sending clients MUST NOT include Stanza-ID elements inside the &content; element, as this would prevent the server from filtering it. A client MUST ignore Stanza-ID elements encountered inside &content; element
Elements of &xep0033; The server MUST be able to access the <addresses/> and <address/> elements in order to do message routing, so they MUST NOT be encrypted.
TODO: Other elements?

Unencrypted &content; elements are NOT ALLOWED as child elements of the stanza and MUST be dropped.

Elements in the &content; elements &payload; element MUST be identified using an element name and namespace. Notably the <body/> element MUST contain a valid namespace (i.e. "jabber:client").

The recipient must verify that the decrypted &content; element contains valid XML before processing it any further. Invalid XML must be rejected.

After verifying the integrity of the &content; element, the recipient needs to make sure that no server-processed elements are found within the payload. Any forbidden elements MUST be dropped before the message is processed any further.

Furthermore the receiving client MUST ignore any extension elements considered as sensitive which are found outside of the &content; element, especially as direct unencrypted child elements of the enclosing stanza.

Since a chat message encrypted with SCE MUST NOT contain a <body/> element, it is not eligible for MAM message storage (&xep0313;). Therefore sending entities MUST append an unencrypted &xep0334; <store/> hint as a direct child element to the message.

As a first, naïve approach a recipient of a message containing an &envelope; element could simply reinject the reassambled unencrypted stanza into the XML stream. This might introduce some security issues. Most notably, depending on the clients implementation it may become ambiguous which elements were received end-to-end encrypted and which were received unencrypted.

Implementations should rather handle encrypted elements explicitly.

For the sake of simplicity, the examples in this document are not encrypted. A real-world implementation MUST make use of real cryptographic protocols.

This specification presents a set of affix elements which can be used to counter certain attacks. However it does not dictate any behaviour regarding what elements MUST be used/verified or when.

Different cryptographic protocols come with different possible attack scenarios which must be taken into consideration, so it is left up to those cryptographic protocols to define profiles that describe the use of affix elements.

TODO: Maybe the Registrar should handle a blacklist of elements that are allowed as child elements of the &content; element?

TODO.

Big thanks to the authors of &xep0373; (Florian Schmaus, Dominik Schürmann and Vincent Breitmoser) which heavily inspired the idea of this protocol.

Also thanks to Marvin Wißfeld, Tim Henkes, Daniel Gultsch, Melvin Keskin and Andreas Straub for their feedback.