----- Forwarded message from joe <joe@stsauver.com> ----- Date: Tue, 27 Jan 2015 22:37:18 -0500 (EST) From: joe <joe@stsauver.com> To: Stephen Farrell <stephen.farrell@cs.tcd.ie> Cc: Jerry Leichter <leichter@lrw.com>, Cryptography <cryptography@metzdowd.com>, Ben Laurie <benl@google.com>, John Gilmore <gnu@toad.com>, grarpamp <grarpamp@gmail.com> Subject: Re: [Cryptography] traffic analysis -> let's write an RFC? Message-ID: <alpine.BSO.2.11.1501272155210.19906@stsauver.com> User-Agent: Alpine 2.11 (BSO 23 2013-08-11) Hi, Stephen Farrell commented:

I think that traffic analysis mitigation is the next big area we need to start trying hard to work. So far, we've (IETF) gotten general padding capabilities added to protocols (HTTP/2.0 for example, still in discussion for TLS1.3) on a case by case basis, but we've not yet done anything systematic. I'd love to see a WG chartered to try figure out how to most effectively counter traffic analysis and then go write protocol and/or BCPs as needed.

While it's possible to talk about some fairly sophisticated anti-traffic analysis strategies, I believe the low hanging fruit for traffic analysis-resistance at the ISP level will likely involve a fairly simple (if ugly) recipe: -- Use crypto at L1 (e.g., optical transport crypto) and/or L2 (e.g., MACsec) to get what opacity you can there -- Use IPv4 with NAT/PAT (with many customer identiies comingled on each public IP; yes, I know that this is awful from an end-to-end transparency POV) -- Combine that with "short" IPv4 DHCP lease times -- Strive for minimal log retention (in reality, given the potential impact of preservation requests, there may need to be NO logging, and yes, that will be pretty bad when considered from an anti-abuse POV) Note: this assumes that non-logging is permitted by law where employed. To the best of my knowledge, there is no required log retention in the United States, and the European Data Retention Directive also got the chop from the European Court of Justice, see for example http://curia.europa.eu/jcms/upload/docs/application/pdf/2014-04/cp140054en.p... (however, as always, this is not legal advice and anyone contemplating this approach should consult their own counsel in picking a strategy) That's my bet for the Internet side, sort of a lightweight/first step for anti-traffic analysis, kin to the lightweight/first step protection that opportunistic encryption provides for SMTP traffic. Obviously this isn't a total solution, but it's a start. [Shame that bulk domestic collection of metadata makes it necessary to even talk about this sort of thing...] Oh yes: what about the cellular side? Let's not forget it, too. The best you may be able to get as an anti-traffic analysis strategy on the phone side may be to use frequently-replaced and infrequently- used simple prepaid cell phones purchased for cash (but note that an increasing number of countries do not even allow purchase and use of unregistered cell phones). Naturally, batteries must be out of cellular devices when the devices aren't actively in use. Yes, this is all a big pain. (But the whole metadata/traffic analysis issue is very difficult to definitively handle without at least some inconvenience, I think.) Regards, Joe St Sauver (joe@stsauver.com) https://www.stsauver.com/joe/ Disclaimer: all opinions strictly my own _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography ----- End forwarded message -----