[Cryptography] traffic analysis -> let's write an RFC?

Eugen Leitl eugen@leitl.org
Wed Jan 28 03:25:49 PST 2015


----- 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.pdf
   (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 -----



More information about the cypherpunks mailing list