Hi Peter,
Thanks for keeping me in the loop. I have two comments. Please find them
below.
On 04/09/2014 01:18 AM, Peter Saint-Andre wrote:
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:
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
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/
Cheers,
Giancarlo
