Subject: Re: [perpass] Traffic analysis

From: "Joe St Sauver" <[email-masked]>
Date: Mon, 28 Oct 2013 09:11:30 -0700 (PDT)

Hi,

Stephen Farrell <[email-masked]> commented:

#Now that we seem to be getting a bit of a handle on the TLS
#related crypto parts of all this, (which are maybe easier
#or more tractable), I think it'd be timely to see some list
#discussion on traffic analysis before Vancouver.
#
#I'd be interested in any less obvious ways in which IETF
#protocols might be making traffic analysis easier than it
#ought be. And of course in countermeasures, but those are
#maybe quite difficult.

Just to quickly summarize a few traffic analytic approaches 
(e.g., analyses that do not consider the contents of traffic) 
at the 10,000 ft level:

-- Sometimes merely knowing that a communication is happening
   between two particular parties conveys significant 
   information.

   A classic example: a government official in a sensitive 
   role begins exchanging non-official messages with a known 
   agent of a foreign power (or an investigative journalist).
   If that was noted, a big red flag might well go up.

-- Sometimes the frequency/volume of communications conveys 
   information that may signal something's afoot.

   For instance, normal traffic volume might be sporadic and 
   brief, but in a crisis period, message count and total 
   message volume might ramp up dramatically. (this is the
   classic "increased volume of chatter" comment sometimes
   mentioned in the press)

   Conversely, if "radio silence" suddenly descends, and
   communications that normally take place suddenly cease,
   that may also be a signal that something's happening.

-- Sequencing can also sometimes be important. Imagine a 
   situation where a report from party A is received by "HQ."

   Shortly thereafter, communications fan out from "HQ" to 
   parties B through Z, perhaps coincidentally, perhaps not.

   If that pattern repeats itself multiple times, we might
   infer that party A is at least somehow "related to" the 
   activities of parties B through Z, in an extreme case, 
   perhaps going so far as to direct the activities of those 
   entities.

How might we hypothetically counter those traffic analytic approaches?
At a very simple level:

-- If the worry is that person-to-person messages unduly
   expose relationships or contacts that might be red flags:

   -- avoid phone calls, emails, IM, and other person-to-person 
   communication channels, 

   -- use one-to-many communications instead (post to Usenet
   News, comment on a web page, send a twitter message, etc.)

-- If communication volume ("chatter") is the issue, send a 
   constant stream of traffic, regardless of whether things
   are sleepy and routine or the exact opposite.

   (FWIW, obviously most IETF protocols are NOT designed to send 
   a constant stream of traffic...)

-- If sequencing is the issue, decouple cause and effect in 
   time or space. If "A" contacts "HQ" and "HQ" then normally
   contacts "B" through "Z", maybe always have HQ send messages 
   to B through Z (and AA-ZZ!) regardless of whether or not A 
   sends a message to HQ or not

Is that the sort of thing you wanted to begin discussing?

Regards,

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Oct 2013 17:47:15 +0000

Hiya,

> (e.g., analyses that do not consider the contents of traffic) 
[...reasonable text elided...]
> Is that the sort of thing you wanted to begin discussing?

Yep. But not at the 10,000ft level:-)

Not quite sure, but I think we might get some benefit at the
moment from considering how specific fields in real protocols
undermine privacy (e.g. as Christian's draft does with the
Received header fields in mail messages) even if/when TLS or
other existing security mechanisms are properly used.

That's not to say that we should immediately try change all
those protocols, since there will likely be (or were once)
good reasons why stuff is done as it is, but there may be
cases where we find that there are specific concrete things
the IETF could be doing and finding those is the goal of our
session in Vancouver.

S.

> 
> Regards,
> 
> Joe
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
> 
>