[Standards] XEP-0138: security considerations
gpellegrino at deeds.informatik.tu-darmstadt.de
Thu Apr 24 16:33:40 UTC 2014
Thanks for keeping me in the loop. I have two comments. Please find them
On 04/09/2014 01:18 AM, Peter Saint-Andre wrote:
> Before we released the security note about application-layer
> compression last week  (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
> 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 ). 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:
Here, I would propose to keep separated data leakage from resource
exhaustion issues. I mean, I would physically separate them into two
distinct subsections each of them covering the following points:
a) description of the security issue(s),
b) security risks and/or known exploitations/attacks,
c) recommendation to avoid/solve them;
> 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.
I kind of would like to adjust my earlier statement in which I suggest
to turn SHOULDs into MUSTs. In my understanding, MUSTs are used to make
sure that a behavior will be shared by two communicating entities... I
mean for the sake of interoperability only. I may be wrong on this and
know more than me, but I just avoid that. Anyway, to make a long story
short: I think that the points a), b) and c) suffice here.
> 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
> 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
More information about the Standards