From 5b588a1876067ac80c772c7718b2537c4bbef3d7 Mon Sep 17 00:00:00 2001 From: Jonas Wielicki Date: Thu, 23 Mar 2017 17:25:13 +0100 Subject: [PATCH] ecaps2 (XEP-0390) to version 0.1 * Some editing * Explicitly mention the possible need for rate-limiting of caps processing in Security Considerations * Reference UTF-8 and Base64 RFCs * Reference U+002E properly * Clarify error condition for Hash Function Input algorithm --- xep-0390.xml | 41 +++++++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git a/xep-0390.xml b/xep-0390.xml index 447f6cc7..9ae182ed 100644 --- a/xep-0390.xml +++ b/xep-0390.xml @@ -15,6 +15,7 @@ + Processing Entity"> Processing Entities"> Generating Entity"> @@ -50,6 +51,12 @@ jonas@wielicki.name jonas@wielicki.name + + 0.1 + 2017-03-23 + jwi +
  • Add security consideration for caps spamming.
  • Properly reference UTF-8 and Base64 RFCs.
  • Remove namespace prefixes from examples.
  • Properly reference &fullstop;.
  • Clarify the first error condition in the Hash Function Input algorithm.
 + 0.0.1 2017-02-28 @@ -62,10 +69,10 @@

XMPP applications often face choices based on the disco#info (see &xep0030;) exposed by other entities. For example, for a client, knowledge about whether a roster entry is a &xep0369; entity or a normal client is important for user experience. It may also be desirable to provide indicators on the type of client a contact is using (mobile or not).

The canonical way to do so has been issueing XEP-0030 requests to the entities emitting presence. This, with the evergrowing featureset of XMPP, induces a lot of traffic for all involed parties, especially during startup. This is a waste of resources, as XEP-0030 information rarely changes and even more, common client configurations and versions share exactly the same information.

&xep0115; has provided the XMPP ecosystem with a way to share this information with less bandwith. Entities using that protocol send a hash of their disco#info result along with presence or stream features. As those hashes can be cached, entities receiving these hashes only need to query the information for each hash once, greatly reducing the Service Discovery traffic.

-

However, XEP-0115 has several flaws:

+

However, XEP-0115 has two main flaws:

@@ -102,9 +109,9 @@

The input to this algorithm is a &xep0030; disco#info <query/> response. The output is an octet string which can be used as input to a hash function or an error.

-

General remarks: The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 encoding is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used.

+

General remarks: The algorithm strongly distinguishes between character data (sequences of Unicode code points) and octet strings (sequences of 8-bit bytes). Whenever character data is encoded to octet strings in the following algorithm, the UTF-8 encoding as specified in &rfc3629; is used. Whenever octet strings are sorted in the following algorithm, the i;octet collation as specified in &rfc4790; is used.

    -
  1. If the <query/> element contains any elements except <identity/>, <feature/> or &xep0128; data forms, abort with an error.
    2. +
  2. If the <query/> element contains any elements except <identity/>, <feature/> (both from the &xep0030; disco#info namespace) or &xep0128; data forms, abort with an error.
  3. If any &xep0128; <x/> element contains a data form which contains a <reported/> or <item/> element, abort with an error.
  4. If any &xep0128; <x/> element does not adhere to the "FORM_TYPE" protocol specified by &xep0068;, abort with an error.

  5. Processing of <feature/> elements:

    @@ -164,13 +171,13 @@

    The &hashnode; is obtained from a &hash; with the following simple algorithm:

    1. To the namespace prefix "urn:xmpp:caps#", append the name of the hash function as per &xep0300;.
      2. -
    2. Append a ".".
      3. -
    3. Append the base64 encoded hash value.
      4. +
    4. Append a &fullstop;.
      5. +
    5. Append the Base64 encoded (as specified in &rfc3548;) hash value.

    The &hashnode; can be decomposed into its original components with the following algorithm:

    1. Remove the namespace prefix "urn:xmpp:caps#" from the input.
      2. -
    2. From the end of the string, start searching for the "." separator.
      3. +
    3. From the end of the string, start searching for the &fullstop; separator.
    4. Split the string into the hash function and the Base64-encoded hash value at the position found in the previous step.
    @@ -316,9 +323,9 @@ 000001d9

    Running this octet string through the hash functions leads as to the following &hashset;:

    - kzBZbkqJ3ADrj7v08reD1qcWUwNGHaidNUgD7nHpiw8= - 79mdYAfU9rEdTOcWDO7UEAt6E56SUzk/g6TnqUeuD9Q= + + kzBZbkqJ3ADrj7v08reD1qcWUwNGHaidNUgD7nHpiw8= + 79mdYAfU9rEdTOcWDO7UEAt6E56SUzk/g6TnqUeuD9Q= ]]> @@ -551,9 +558,9 @@ cDp0aW1lHxw= 00000543

    Feeding the concatenated octet string as input to the hash functions yields the following &hashset;:

    - u79ZroNJbdSWhdSp311mddz44oHHPsEBntQ5b1jqBSY= - XpUJzLAc93258sMECZ3FJpebkzuyNXDzRNwQog8eycg= + + u79ZroNJbdSWhdSp311mddz44oHHPsEBntQ5b1jqBSY= + XpUJzLAc93258sMECZ3FJpebkzuyNXDzRNwQog8eycg= ]]>     @@ -723,7 +730,7 @@ cDp0aW1lHxw=
    • Entities MAY limit the rate at which they process incoming &hashsets;.
      • -
    • Entities MUST be able to process &hashnodes; which use a hash function whose name includes the "." character.
      • +
    • Entities MUST be able to process &hashnodes; which use a hash function whose name includes the &fullstop;.
    • Entities MAY verify incoming &hashsets;.
    • Entities MUST NOT expect to receive &hashsets; on every presence sent by an entity supporting ∩︀.
    @@ -758,13 +765,14 @@ cDp0aW1lHxw= -

    The codepoints used for separating the different parts in the Hash Function Input Algortihm (&sepl4; through &sepl1;) are not allowed in well-formed XML character data. As entities are, per &xmppcore;, required to close a stream if non-well-formed XML data is received, these codepoints cannot occur in the input to the algorithm and their use as separators is safe.

    +

    The codepoints used for separating the different parts in the Hash Function Input Algortihm (&sepl1; through &sepl4;) are not allowed in well-formed XML character data. As entities are, per &xmppcore;, required to close a stream if non-well-formed XML data is received, these codepoints cannot occur in the input to the algorithm and their use as separators is safe.

    If the algorithm for constructing the input to the hash function or the used hash function itself allow for cheap collisions, caching the hashes will become dangerous as it allows for cache poisoning. This in turn allows entities to effectively fake disco#info responses of other entities.

    This was an issue with &xep0115; and has been addressed with a new algorithm for generating the hash function input which keeps the structural information of the disco#info input.

    An entity MUST NOT ever use disco#info which has not been verified to belong to a &hash; obtained from a cache using that &hash;. Using cache contents from a trusted source (at the discretion of the entity) counts as verifying.

    +

    A malicious entity could send a large amount of &hashsets; in short intervals, while making sure that it provides matching disco#info responses. If a &procent; uses caching, this can overflow or thrash the caches. &procents; should be aware of this risk and apply proper rate-limiting for processing &hashsets;. To reduce the attack surface, an entity MAY choose to not cache &hashes; obtained from entities not in its roster.

     @@ -837,6 +845,7 @@ cDp0aW1lHxw=

    Thanks to the authors of &xep0115; for coming up with the original idea of using presence broadcast to convey service discovery information, as well as the optimization strategies.

    The note below the example in Advertisement of Support and Capabilities by Servers has been copied verbatimly from XEP-0115.

    Thanks to Waqas Hussain for originally (to my knowledge) pointing out the security flaws in XEP-0115 (see &mlwaqas1;).

    +

    Thanks to Georg Lukas, Link Mauve, Sebastian Riese, Florian Schmaus and Sam Whithed for their input, editorial and otherwise.