[Standards] XEP-0138: security considerations

Giancarlo Pellegrino gpellegrino at deeds.informatik.tu-darmstadt.de
Thu Apr 24 16:33:40 UTC 2014


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




More information about the Standards mailing list