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

Dean Willis <> Fri, 18 March 2011 20:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 248683A6A33 for <>; Fri, 18 Mar 2011 13:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.355
X-Spam-Status: No, score=-103.355 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qmIpONP6l-cR for <>; Fri, 18 Mar 2011 13:56:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 305ED3A69A7 for <>; Fri, 18 Mar 2011 13:56:32 -0700 (PDT)
Received: by yxk30 with SMTP id 30so2054475yxk.31 for <>; Fri, 18 Mar 2011 13:58:01 -0700 (PDT)
Received: by with SMTP id k6mr1653117agj.123.1300481881673; Fri, 18 Mar 2011 13:58:01 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id w4sm468926anw.42.2011. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 Mar 2011 13:58:01 -0700 (PDT)
References: <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
Message-Id: <>
Content-Transfer-Encoding: quoted-printable
From: Dean Willis <>
Date: Fri, 18 Mar 2011 15:57:59 -0500
To: Fearghas McKay <>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [obscurity-interest] Prague face-to-face scheduling
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion of communications obscurity and real-time communications." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Mar 2011 20:56:33 -0000

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.