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

From: Dean Willis <[email-masked]>
Date: Fri, 18 Mar 2011 11:40:43 -0500

Apparently our room-request was a bit behind the crowds, so the official meeting rooms are blocked up. This puts us in bar-bof-land, which is probably where we ought to be anyhow.

The Hilton's bar facililties are amenable to discussion groups, but outrageously priced. This might work well for a kick-off, where we could meet-and-greet at the Hilton bar, then decide what to do next.

How about an initial meet up Monday evening, immediately post-plenary, in the Hilton bar?

--
Dean

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 18 Mar 2011 09:47:10 -0700

> How about an initial meet up Monday evening, immediately post-plenary, in the Hilton bar?

Works for me.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 18 Mar 2011 13:03:31 -0400

I'm assuming that the phrase "counter-communication" refers to 
interaction at an institutional "counter", and sensitive data is 
communicated, e.g., personally identifying information and 
pharmaceutical prescriptions or banking identifiers, etc.

Is this a correct assumption?

Thanks in advance,
Eric

On 3/16/11 9:04 PM, IETF Secretariat wrote:
> A new IETF non-working group email list has been created.
>
> List address: [email-masked]
> Archive: http://www.ietf.org/mail-archive/web/obscurity-interest/
> To subscribe: https://www.ietf.org/mailman/listinfo/obscurity-interest
>
> Description:  This list is for discussion of the requirements and
> technology for enabling communications, especially near or real-time,
> between persons subject to high levels of counter-communication
> interception. The requirements are believed to relate to privacy, data
> integrity, unlinkability, and the general intercept (lawful or otherwise)
> problem, which is broader than the "privacy" problem considered by IETF.
> This list intended to focus on practical requirement and actionable work
> rather than general theory. Discussion may lead to new protocol action,
> enhanced guidance for "security considerations" sections in IETF
> specifications, and further research inside or outside of the IETF.
>
> For additional information, please contact the list administrators.
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Mar 2011 13:02:06 -0500

I confess I did not have that particular definition in mind, but it
certainly represents an interesting use case.

On Mar 18, 2011 12:03 PM, "Eric Brunner-Williams" <[email-masked]>
wrote:

I'm assuming that the phrase "counter-communication" refers to interaction
at an institutional "counter", and sensitive data is communicated, e.g.,
personally identifying information and pharmaceutical prescriptions or
banking identifiers, etc.

Thanks in advance,
Eric

_______________________________________________
obscurity-interest mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/obscurity-interest

---

From: Fearghas McKay <[email-masked]>
Date: Fri, 18 Mar 2011 18:12:41 +0000

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 ? 

	f

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 18 Mar 2011 14:13:48 -0400

As an alternative to continued guessing, perhaps you could share the 
particular definition(s) you have in mind.

On 3/18/11 2:02 PM, Dean Willis wrote:
>> On Mar 18, 2011 12:03 PM, "Eric Brunner-Williams"
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     <mailto:[email-masked]>
>>     To subscribe:
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Mar 2011 15:57:59 -0500

> 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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 18 Mar 2011 19:45:14 -0400

Inline.

> 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 sub…

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

> 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…

I appreciate that your response is informal.

> 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.

Eric