On 30 Sep 2013, at 8:10 , "d.nix" <[email protected]> wrote:
> On 9/29/2013 10:35 PM, Christian Huitema wrote: > > > Traffic analysis proceeds through the collection of "meta data" > > such as ip headers, e-mail headers, and other forms of signaling, > > e.g. SIP headers. DNS traffic analysis also falls in that category. > > Such data is easy to harvest by monitoring big conduits such as > > backbone links or submarine cables. In some countries, the data is > > collected by forcing traffic through a single exchange or through > > some form of "national firewall." > > > > The current internet protocols and applications pay very little > > attention to traffic analysis. We should obviously take the easy > > steps, encrypt the DNS, e-mail and SIP connections. But when it > > comes to IP header analysis, we have pretty few solutions. VPN, of > > course, but that requires configuration. Could we change that? > > > > I feel in general, that while we can go a long way towards making > content encryption easier and more robust, and simple to use for non > tech savvy users (ie, your parents, aunts, uncles, etc...), *the* > single largest issue is traffic analysis of message headers. > > While there are legit concerns by people to troubleshoot and to > identify sources of spam and bulk mail, it's just entirely too easy to > build up graphs of communication patterns and who is contacting who > and when they are doing it. While traffic analysis can be applied to several areas of investigation, this is the most directly relevant to "intelligence gathering", and can be defended against as you say: prevent leakage of identifying information (which you must be _very_ good at if defense against identification and association is to work -- one weak observable link and you might as well have done nothing). > VPN's are a possibility, but as you say, > require careful configuration and setup to prevent leakage of > identifying information. Tech that purports to secure or privatize > your communication but that actually leaks - or worse, can be coerced > into revealing your traffic, is worse than no tech at all. > > Mix networks, anonymous remailers, and alternative / out of band > systems start looking worthy of a lot more study. These are good architectural defenses against association attacks, but come with (often high) bandwidth and latency costs, as well as additional operating expenses. Another area of investigation is behavioral classification and fingerprinting: associating given encrypted traffic with an underlying protocol or activity. The old SSH keystroke timing attack [1] worked this way, as well as related identification attacks on anonymized trace data [2]. This is a completely different type of attack. Defense requires fingerprint resistance built into the protocol design: in an end-to-end, point-to-point encrypted communication system which, as most protocols _implicitly_ are, is optimized somewhere close to the minimal-bandwidth/minimal-latency curve, the presence of traffic on the wire means "someone's using the system", which given access to other information can be enough to answer interesting questions about associations. Fingerprint resistance necessarily pushes the protocol away from this curve (with associated costs both in bandwidth and latency), and must also be done with attention to detail. Even Skype, a protocol which resists classification to resist blocking by ISPs which provided access to its customers while competing with it, left a signal reasonably well visible in flow data as part of its client association process [3] as of 2011, which at least allowed a single-flow identification of clients and supernodes. So, I've been thinking about traffic analysis resistance recently (as I suppose a lot of people have :) ) and the question starts coming down to how much resistance for what cost, and is there a point at which we can get a significant win in the face of pervasive surveillance before the point in the cost benefit curve in which we start giving up things we'd really like to keep (acceptable latency/jitter for voice/video, acceptable bandwidth for a given cost, identification and prevention of email abuse, etc.) Best regards, Brian [1] Song et al "Analysis of Keystrokes and Timing Attacks on SSH", USENIX Security 2001 [2] Coull et al, "Playing Devil’s Advocate: Inferring Sensitive Information from Anonymized Network Traces", NDSS 2007 [3] Trammell et al, "Identifying Skype Traffic in a Large-Scale Flow Data Repository", TMA 2011 > Dave Nix > > BM-2D9jC7gYDpnfprbSXuTCGr6a2DsCAXssAc (bitmessage) > > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
