xeps/xep-0420.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY content "&lt;content/&gt;">
  <!ENTITY envelope "&lt;envelope/&gt;">
  <!ENTITY payload "&lt;payload/&gt;">
  <!ENTITY time "&lt;time/&gt;">
  <!ENTITY rpad "&lt;rpad/&gt;">
  <!ENTITY to "&lt;to/&gt;">
  <!ENTITY from "&lt;from/&gt;">
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Stanza Content Encryption</title>
  <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>
  &LEGALNOTICE;
  <number>0420</number>
  <status>Experimental</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XEP-0001</spec>
    <spec>Etc.</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>SCE</shortname>
  <author>
    <firstname>Paul</firstname>
    <surname>Schaub</surname>
    <email>vanitasvitae@fsfe.org</email>
    <jid>vanitasvitae@jabberhead.tk</jid>
  </author>
  <revision>
    <version>0.1.0</version>
    <date>2019-07-30</date>
    <initials>XEP Editor (jsc)</initials>
    <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>

<section1 topic='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. <link url="https://xmpp.org/extensions/xep-0373.html#example-2">&lt;signcrypt&gt;</link>) introduced by &xep0373; for the use with other encryption protocols.</p>

</section1>

<section1 topic='Requirements' anchor='reqs'>
  <p>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.</p>

  <p>In order to achieve its goal, Stanza Content Encryption does the following:</p>
  <ul>
    <li>Define elements that hold sensitive information and their encrypted form</li>
    <li>Speficy rules about how extension elements are encrypted and embedded in the message</li>
    <li>Specify rules about which elements are allowed inside and outside the protected domain</li>
  </ul>
</section1>

<section1 topic='Glossary' anchor='glossary'>
  <dl>
    <di><dt>Envelope Element &envelope;</dt><dd>An XMPP extension element which is used to hold the encrypted &content; element.</dd></di>
    <di><dt>Content Element &content;</dt><dd>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.</dd></di>
  </dl>
</section1>

<section1 topic='Affix Elements' anchor='affix_elements'>
  <p>In order to prevent certain attacks, different affix elements MAY be added into the &content; element.</p>

  <table caption='Overview about different crypto property elements'>
    <tr>
      <th>Element</th>
      <th>Description</th>
      <th>Usage</th>
      <th>Verification</th>
    </tr>
    <tr>
      <td>&rpad;</td>
      <td>Random-length random-content padding</td>
      <td>Prevent known ciphertext and message length correlation attacks</td>
      <td>None. This element is only used to change the length of the ciphertext and doesn't need to be verified</td>
    </tr>
    <tr>
      <td>&time;</td>
      <td>Timestamp</td>
      <td>Prevent replay attacks using old messages</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>
    </tr>
    <tr>
      <td>&to;</td>
      <td>Recipient of the message</td>
      <td>Prevent spoofing of the recipient</td>
      <td>Receiving clients MUST check, if they are recipient of the message and otherwise alert the user/reject the message</td>
    </tr>
    <tr>
      <td>&from;</td>
      <td>Sender of the message</td>
      <td>Prevent spoofing of the sender</td>
      <td>Receiving clients MUST check, if the content of the from element matches the from attribute of the enclosing stanza and otherwise alert the user/reject the message</td>
    </tr>
  </table>

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

</section1>

<section1 topic='Use Cases' anchor='usecases'>
  <p>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.</p>

  <example caption='The Narrator sends an imperfectly encrypted message, leaking dangerous information about the conversation through the OOB extension element.'><![CDATA[
<message from='narrator@jabber.org'
         to='viewer@jabber.org'>
  <encrypted xmlns='eu.siacs.conversations.axolotl'>
    <header sid='27183'>
      ...
    </header>
    <payload>
      SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMsIHRoZXNlIGFyZSBi
      cnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdpdGggdGhhdC4gSSBh
      bSBlbmxpZ2h0ZW5lZC4=
    </payload>
  </encrypted>
  <x xmlns='jabber:x:oob'>
    <url>https://en.wikipedia.org/wiki/Fight_Club#Plot</url>
  </x>
</message>]]>
  </example>
  <p>The example above obviously leaks information about the communication through the unencrypted OOB extension element.</p>

  <p>Another example of a possible use case would be encrypted &lt;iq/&gt; 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.</p>
</section1>

<section1 topic='Sending an encrypted message' anchor='sending'>
  <p>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.</p>

  <example caption='Content element containing the messages body and the OBB element.'><![CDATA[
<content xmlns='urn:xmpp:sce:0'>
  <payload>
    <body xmlns='jabber:client'>[...]</body>
    <x xmlns='jabber:x:oob'>
      <url>https://en.wikipedia.org/wiki/Fight_Club#Plot</url>
    </x>
  </payload>
</content>]]>
  </example>

  <p>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.</p>

  <example caption='Same message as in the previous example but encrypted using Stanza Content Encryption to also protect the OBB extension element.'><![CDATA[
<message from='narrator@jabber.org'
         to='viewer@jabber.org'>
  <encrypted xmlns='eu.siacs.conversations.axolotl'>
    <header sid='27183'>
      ...
    </header>
    <envelope xmlns='urn:xmpp:sce:0'>
      PGNvbnRlbnQgeG1sbnM9J3Vybjp4bXBwOnNjZTowJz48cGF5bG9hZD48Ym9keSB4bWxucz0namFi
      YmVyOmNsaWVudCc+SSBnb3QgaW4gZXZlcnlvbmUncyBob3N0aWxlIGxpdHRsZSBmYWNlLiBZZXMs
      IHRoZXNlIGFyZSBicnVpc2VzIGZyb20gZmlnaHRpbmcuIFllcywgSSdtIGNvbWZvcnRhYmxlIHdp
      dGggdGhhdC4gSSBhbSBlbmxpZ2h0ZW5lZC48L2JvZHk+PHggeG1sbnM9J2phYmJlcjp4Om9vYic+
      PHVybD5odHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9GaWdodF9DbHViI1Bsb3Q8L3VybD48
      L3g+PC9wYXlsb2FkPjwvY29udGVudD4=
    </envelope>
  </encrypted>
</message>]]>
  </example>

  <p>The message can then be sent to the recipient.</p>
</section1>

<section1 topic='Receiving an encrypted message' anchor='receiving'>
  <p>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.</p>
  <p>Next the extension elements of the &content; elements &payload; element are checked against the whitelist/blacklist and any disallowed elements are discarded.</p>
  <p>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.</p>
</section1>

<section1 topic='Blacklist' anchor='blacklist'>
  <p>The receiving client MUST ignore certain elements that may allow for attacks to take place.</p>
  <p>Since it is hard to come up with a complete list of blacklisted elements, a general rule of thumb would be the following:</p>
  <p>Blacklisted are all elements that need to be read by the server at some point.</p>
  <p>Below is an additional list of elements that are definitely forbidden inside the &content; element and MUST instead be placed in the message unencrypted.</p>
  <table caption='Examples for elements that MUST be ignored by the recipient'>
    <tr>
      <th>Element</th>
      <th>Reason</th>
    </tr>
    <tr>
      <td>Elements of &xep0334;</td>
      <td>Those elements are addressed to the server and of no interest for the client</td>
    </tr>
    <tr>
      <td>Origin-ID elements of &xep0359;</td>
      <td>These IDs may be used to identify a message even though it cannot be decrypted.</td>
    </tr>
    <tr>
      <td>TODO: Other elements?</td>
      <td></td>
    </tr>
  </table>

</section1>

<section1 topic='Business Rules' anchor='rules'>
  <p>Unencrypted &content; elements are NOT ALLOWED as child elements of the stanza and MUST be dropped.</p>
  <p>Elements in the &content; element MUST be identified using an element name and namespace. Notably the &lt;body/&gt; element MUST contain a valid namespace (i.e. "jabber:client").</p>
  <p>Recipient must verify that the decrypted &content; element contains valid XML before processing it any further. Invalid XML must be rejected.</p>
  <p>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.</p>
  <p>Duplicate elements within the &content; element MUST be dropped.</p>
  <p>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?</p>
</section1>

<section1 topic='Implementation Notes' anchor='impl'>
  <p>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.</p>
  <p>Implementations should rather handle encrypted elements explicitly.</p>
</section1>

<section1 topic='Security Considerations' anchor='security'>
  <section2 topic='Encryption Profiles' anchor='security_profiles'>
    <p>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.</p>
    <p>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.</p>
  </section2>
</section1>

<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>TODO: Maybe the Registrar should handle a blacklist of elements that are allowed as child elements of the &content; element?</p>
</section1>

<section1 topic='XML Schema' anchor='schema'>
  <p>TODO.</p>
</section1>
</xep>