Re: [obscurity-interest] Prague face-to-face scheduling

[Eric Brunner-Williams <[e-mail]>]

Inline.

On 3/18/11 4:57 PM, Dean Willis wrote:
>
> On Mar 18, 2011, at 1:12 PM, Fearghas McKay wrote:
>
>>
>> On 18 Mar 2011, at 18:02, Dean Willis wrote:
>>
>>> I confess I did not have that particular definition in mind, but it certainly represents an interesting use case.
>>
>> What was your primary use case ?
>
>
> This is a good question for us to discuss.
>
> I think we've heard a couple of use-cases come up, some of which are probably more applicable than others to this particular venue. So let;s see if we can start nailing it down.
>
> The scenario that I had in mind is political discourse under oppressive regimes, where Internet access is available, but is being monitored to some extent by the security/police apparatus, with two particular consequences:
>
> 1)  Participants in the communications channel are singled-out for "off-net" enforcement, like having the death squad show up at their house at 0200 and them never being seen again (We lose so many death squads that way!). This has several subcases:
> a) Using simple address-and-port matching to link victims with the channel
> b) Using deep-packet inspection to link victims with the channel
> c) Taking over the servers of the channel and pulling out subscriber-identifying information, such as IP addresses, browser signatures, and the like
> d) Planting spies "in the channel" to report back.
> e) Running the entire channel as a honeypot to identify subversives.
> f) Matching the profiles of channel utterances to observed  on-net events. For example, user Alice tweeted into a public channel at 15:04:32.50, and network logging showed traffic between local subscriber Ali and Twitter, having approximately the right payload size, at 15:04:32.20, therefor Ali is linked to Alice.

This includes passive techniques: traffic analysis, content analysis, 
and active techniques: content and traffic generation.

> 2) The regime "shutting down" the channel, which itself has several sub-cases:
>
> a) blocking name resolution of the channel
> b) address-and-port blocking the channel
> c) using deep-packet inspection tools to identify and discard packets associated with the channel.
>
> Now, there's certainly a more "politically discrete" way to phrase this set of use cases. Probably a less discrete approach, too, so at least I'm not putting my foot as far into my mouth as I might possibly could.

I appreciate that your response is informal.

> We can envision a broad range of techniques for dealing with these threats, ranging from developing new parallel or over-the-top network topologies, use of address-obscuring technologies such as TOR, use of peer-to-peer technologies (RELOAD?) to applied steganography.
>
> We can think about linking-avoidance guidance for the specific use-case, although broader consideration of anti-linking is probably an ietf-privacy consideration.

It may be helpful to adopt a known nomenclature, "link" could be a 
reference to an intercept-capable media, such as 802.3 or 802.11, or 
it could be a URI, or it could be an instance of correlation between 
elements of two or more data sets, such as data collected via HTTP 
State Management Mechanism instances, or the equivalents, and data 
sold by Equifax, or its competitors, to correlate on-line commercial 
activity such as movie rental data and off-line commercial activity 
such as credit and mortgage data.

> We might also think about things we would like to see added to security considerations of other protocols in order to make the job of obscuring our "protected" communications easier. What we probably don't want to do is open up the general privacy considerations question; that's the ietf-privacy mailing lists' main topic.
>
>
> --
> Dean

Eric