diff --git a/xep-0420.xml b/xep-0420.xml index c07765bf..e7fa388f 100644 --- a/xep-0420.xml +++ b/xep-0420.xml @@ -29,12 +29,19 @@ SCE - - Paul - Schaub - vanitasvitae@fsfe.org - vanitasvitae@jabberhead.tk - + &paulschaub; + + 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 @@ -99,7 +106,7 @@ &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 base64 characters of random length between 0 and 200 characters. TODO: sane boundaries? + 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 @@ -320,23 +327,30 @@

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.

- -

The receiving client MUST ignore certain elements that may allow for attacks to take place.

-

Since it is hard to come up with a complete list of blacklisted elements, a general rule of thumb would be the following:

-

Blacklisted are all elements that need to be read by the server at some point.

-

Below is an additional list of elements that are definitely forbidden inside the &content; element and MUST instead be placed in the message unencrypted.

- + +

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.

+
- + - - + + + + + + @@ -348,17 +362,21 @@

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").

+

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.

+

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, there is no way to distinguish end-to-end encrypted elements from unencrypted elements.

+

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.

 @@ -377,4 +395,9 @@

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.

+
Element Reason
Elements of &xep0334;Those elements are addressed to the server and of no interest for the clientMessage 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
Origin-ID elements of &xep0359;These IDs may be used to identify a message even though it cannot be decrypted.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?