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