[Standards] R: XEP-0138: security considerations

Sergey Dobrov binary at jrudevels.org
Sun Apr 13 12:34:09 UTC 2014


There are two things I can say here:
  * I believe that de-facto servers use 64KB limit now, I may be wrong :)
  * I also believe that we need to reduce data that's being sent with 
base64 by sending them out of band, but anyway 64KB seems to be fine to me.

On 09/04/2014 15:36, Marco Cirillo wrote:
> I have the impression 10 KBs may be too low for stanzas which contain
> binary encoded payloads (e.g. vcard avatars), correct me if I'm wrong.
>
> Marco.
>
>
> -------- Messaggio originale --------
> Da: Peter Saint-Andre
> Data:09/04/2014 01:18 (GMT+01:00)
> A: XMPP Standards
> Cc: Giancarlo Pellegrino
> Oggetto: [Standards] XEP-0138: security considerations
>
> Before we released the security note about application-layer compression
> last week [1] (which now seems to have been overshadowed by the
> heartbleed bug in OpenSSL), I started to work on some updates to
> XEP-0138. Here is my proposed text for the Security Considerations section:
>
> ###
>
> 7. Security Considerations
>
> Stream encryption via TLS (as defined in RFC 6120) and stream
> compression (as defined herein) are not mutually exclusive. However, if
> both are used then TLS-layer encryption MUST be negotiated before
> negotiation of application-layer compression, so that the stream is
> secured first.
>
> Many of the security considerations related to TLS compression (see
> Section 6 of RFC 3749) also apply to stream compression.
>
> Several attacks against TLS-layer and application-layer compression have
> been found, including the CRIME and BEAST attacks (see
> draft-sheffer-uta-tls-attacks [7]). Mitigation for the CRIME attack
> involves disabling TLS-layer compression. At the time of this writing
> (early 2014), there are no general mitigations against the BEAST attack.
> However, the following safeguards are appropriate:
>
>     1. A server implementation MUST NOT turn on compression by default;
> instead, it MUST enable a server administrator to turn on compression if
> desired.
>     2. A server implementation MUST enable a server administrator to
> limit the size of stanzas it will accept from a connected client or peer
> server, and also MUST set a reasonable default limit of at least 10,000
> bytes. In general, it is reasonable for the maximum stanza size to be
> the same as the size of the buffer passed to zlib when storing
> uncompressed data.
>     3. A server implementation MUST enable a server administrator to
> limit the amount of bandwidth it will allow a connected client or peer
> server to use in a given time period.
>
> The last two requirements are consistent with but stronger than
> recommendations provided in Section 13.2 of RFC 6120. Failure to provide
> such protections opens an implementation denial of service attacks.
>
> ###
>
> Your feedback is welcome.
>
> (I have cc'd Giancarlo Pellegrino, who reported the "xmppbomb"
> vulnerability; please reply to all so that he can be included in the
> conversation.)
>
> Thanks!
>
> Peter
>
> [1]
> http://xmpp.org/resources/security-notices/uncontrolled-resource-consumption-with-highly-compressed-xmpp-stanzas/




More information about the Standards mailing list