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

[Dean Willis <[e-mail]>]

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.


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.


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.

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