Hi all, XMPP relies on the TLS protocol to get secrecy and authentication of the exchanged stanzas. What TLS does not conceal from an eavesdropper, though, is the bandwidth used by the XMPP messages.
Now, this could be exploited to de-anonymize users (e.g. by inspecting the size of your avatar, or of your rooster -- see [1] for an example in the HTTP domain), or to understand who are the participants of a private room, by looking at the pattern-size of sent/received messages. Such attacks may require significant network eavesdropping capability, and hence may not be doable on a large scale; yet ISPs, governments etc may effectively run such attacks, at least on targeted users. Moreover, it seems different application protocols may be affected by such traffic analysis, at least including HTTP (see example above), and SMTP (e.g. telling to which mailing lists you're subscribed, by the size of messages you receive). Of course, a countermeasure to this is to pad the size of exchanged messages. I believe the application protocol (XMPP here) must be traffic-analysis aware to optimise the amount of padding: e.g. only pad privacy-sensitive data. However, I think the padding details (where to put the padding, how to make sure it is indistinguishable from real payload, etc…) can be effectively handled within the TLS protocol, rather than at the application level, so that several applications can benefit from the feature. To make an analogy, an XMPP application can have a security policy (e.g. the user picks between "always use strong encryption"; "prefer encryption on"; "prefer encryption off"), and then uses TLS to implement the encryption details. Similarly, the XMPP application identifies privacy-sensitive data whose size needs to be protected, and then uses TLS to get this padding done. I have proposed this TLS padding extension as an I-D [2]. It deals with some internal TLS details, but from the application point of view, this amounts to an extended interface to TLS sockets, where roughly a standard send(char* data, int size) is replaced by a send(char* data, int payload_size, int padded_size) where payload_size is the amount of real transferred payload, and padded_size is the size an eavesdropper should instead be able to infer from the wire. I'd like to hear your feedback. Do you think this is useful? Would you patch your implementation to make use of this feature? I'd like to understand if there's enough consensus from TLS users for this to become a standard TLS extension. If you want to try it out, be informed that GnuTLS [3] already implements this extension, so you're free to play with it. I'm also around at IETF87, so find me in a hall if you want to discuss live. [1] http://hal.inria.fr/docs/00/73/29/55/PDF/RR-8067.pdf [2] http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 [3] http://www.gnutls.org/ Cheers, Alfredo
