[Standards] Feedback on traffic analysis countermeasure
alfredo.pironti at inria.fr
Tue Jul 30 10:06:24 UTC 2013
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  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
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 . 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  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.
More information about the Standards