In order to achieve its goal, Stanza Content Encryption does the following:
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. 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.
+The example above obviously leaks information about the communication through the unencrypted OOB extension element.
-Another example of a possible use case would be encrypted <iq/> queries. A resource might want to query sensitive information from another resource capable of Stanza Content Encryption. This problem can also be solved using SCE.
+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.
+ +To fix the issue of leaking extension elements using Stanza Content Encryption, the sender prepares the message by placing the content elements inside the &content; element.
+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.
-The &content; element is then serialized into XML and encrypted using the encryption mechanism in place. The result is embedded in the &envelope; element and appended to the message.
- -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.
+ +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.
@@ -215,11 +331,13 @@Unencrypted &content; elements are NOT ALLOWED as child elements of the stanza and MUST be dropped.
-Elements in the &content; element MUST be identified using an element name and namespace. Notably the <body/> element MUST contain a valid namespace (i.e. "jabber:client").
-Recipient must verify that the decrypted &content; element contains valid XML before processing it any further. Invalid XML must be rejected.
+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 blacklisted 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.
Duplicate elements within the &content; element MUST be dropped.
Elements in the &content; element override elements in the enclosing stanza. TODO: Maybe we want to remove this rule by disallowing duplicate elements all together?
+Since a 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.
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.