[Cryptography] traffic analysis -> let's write an RFC?
Eugen Leitl
eugen at leitl.org
Wed Jan 28 03:25:49 PST 2015
----- Forwarded message from joe <joe at stsauver.com> -----
Date: Tue, 27 Jan 2015 22:37:18 -0500 (EST)
From: joe <joe at stsauver.com>
To: Stephen Farrell <stephen.farrell at cs.tcd.ie>
Cc: Jerry Leichter <leichter at lrw.com>, Cryptography <cryptography at metzdowd.com>, Ben Laurie <benl at google.com>, John Gilmore
<gnu at toad.com>, grarpamp <grarpamp at gmail.com>
Subject: Re: [Cryptography] traffic analysis -> let's write an RFC?
Message-ID: <alpine.BSO.2.11.1501272155210.19906 at 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 at stsauver.com)
https://www.stsauver.com/joe/
Disclaimer: all opinions strictly my own
_______________________________________________
The cryptography mailing list
cryptography at metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
----- End forwarded message -----
More information about the cypherpunks
mailing list