Subject: [privacydir] Privacy Terminology: What are useful terms?

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 5 Jul 2011 13:48:59 +0300

Hi all, 

You may have seen that the privacy terminology document over time got shorter and shorter as I removed content to make it more readable. Here is the latest version: 
http://tools.ietf.org/html/draft-hansen-privacy-terminology-02

It is still too long. Most IETF document authors are likely to use only a few terms. 

In a recent discussion in the IAB privacy program we were wondering what are the terms we absolutely need to have. Here are the terms I think could be useful for IETF document authors to know. 

1) Anonymity
2) Unlinkability
3) Unobservability
4) Pseudonym/Pseudonymity

Anonymity, unlinkability and pseudonymity are useful terms for many of the IETF's authentication protocols. The sub-categories of sender anonymity and relationship anonymity are more applicable to protocols like onion routing proposals. 
Unobservability shows up in the context of security protocols where dummy traffic is used to pad exchanged data.

Identity management is often touched in the work on architectures. While many of the entities have their own unique terms with each proposal there are some concepts that seem to be quite generic, such as 'identity', and 'identifier'. It may be useful to capture this aspect as well. 

From your experience, what other terminology is useful to have? 

Ciao
Hannes

---

From: Nick Mathewson <[email-masked]>
Date: Fri, 8 Jul 2011 14:40:00 -0400

Hello, Hannes!

On Tue, Jul 5, 2011 at 6:48 AM, Hannes Tschofenig
<[email-masked]> wrote:
 [...]
> From your experience, what other terminology is useful to have?

I'm going to answer from the perspective of my own work on anonymity
and privacy with Tor, recognizing that not everybody's needs are the
same as our own.

We use "Linkability" and subject "Anonymity" in approximately the same
ways that you do.  (We mostly use the "attacker cannot sufficiently
distinguish" formulation, not the "Attacker cannot distinguish"
formulation.  In practice, the attacker's inability to link X and Y
with certainty is mostly useless if the attacker can nevertheless link
X and Y with strong probability.  When we're being precise, we use
these terms to mean the degree of the attacker's uncertainty.)

We also use "Anonymity" to refer to unlinkability between an IOI and its origin.

We use a stronger definition of "pseudonym": we only consider X to be
a pseudonym when it is an identifier that is unlinkable to its subject
by an attacker of interest.  (Thus, by our lights, "Batman" is a
pseudonym since Batman's enemies do not know he is Bruce Wayne, but
"Ad-Rock" is not a pseudonym since Beastie Boys fans worldwide know
that he is really Adam Horovitz.)

We don't use "undetectability" or "unobservability".

Some additional terminology in common use that we use:

   * Instead of "sender" and "receiver" anonymity, we usually speak of
"initiator" and "responder" anonymity.  (In systems that provide
bidirectional communication, most everybody "sends" and "receives".)

   * We talk about one kind of or item being "distinguishable" from
another.  (For example, a protocol is "indistinguishable" from HTTPS
to the extent that an attacker can't tell instances of that protocol
from regular HTTPS connections.)

  * We use "profiling" to mean learning information about an anonymous
subject's activities without necessarily linking them to any specific
transaction.  For example, if an attacker concludes that I play WoW,
read reddit.com, and upload videos, then my activities have been
profiled, even if the attacker is unable to identity which connections
or accounts are mine.

Some additional terminology that I think might be idiosyncratic:

   * We use "linkable session" to refer to a set of actions by a
subject that the system makes no effort to render unlinkable from one
another.

   * We refer as a "linking identifier" to any parameter P that an
attacker can observe about an IOI and use to link it to similar IOIs
that have similar values for P.  For example, the window size header
transmitted in a typical HTTP request is a linking identifier.

Many thanks for all your work here!

yrs,
-- 
Nick

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 13 Jul 2011 12:39:57 +0300

Hi Nick, 

thank you for your feedback. I like the examples you provided. 
It may be useful to add examples to the draft as well to make the text more interesting to read. 

> that he is really Adam Horovitz.)

Ok. 

> We don't use "undetectability" or "unobservability".
I have seen the unobservability term being used in security protocols when the traffic characteristics shall be hidden (via padding). 
Aren't you doing something similar in Tor? If you do, how do you call that property? 

> bidirectional communication, most everybody "sends" and "receives".)
Such a change makes sense to me. We actually use these terms in various IETF protocols as well. 
IKEv2, for example, talks about initiator and responder for exactly the same reason. 

> from regular HTTPS connections.)

Could be useful. 

> profiled, even if the attacker is unable to identity which connections

Profiling may be a useful term to add. 
Btw, I searched through the Tor documents and couldn't really find a definition. 

> subject that the system makes no effort to render unlinkable from one

Could you provide an example? 

> transmitted in a typical HTTP request is a linking identifier.
I wasn't aware that the window size header has such a characteristic. 
Is there a paper you could recommend to learn more about this aspect? 

> Many thanks for all your work here!
Thanks for the review. 

Ciao
Hannes

---

From: Nick Mathewson <[email-masked]>
Date: Sat, 16 Jul 2011 00:14:54 -0400

> Aren't you doing something similar in Tor? If you do, how do you call that property?

Well, we don't actually do enough padding right now to make many
interesting characteristics unobservable.  When we talk about padding,
we usually talk not in terms of making the real traffic volume
unobservable so much as we talk about making the padded view of a
traffic stream unlinkable to an unpadded view.

When we're talking in general about a particular unobservable
property, we tend to use the active voice.  Rather than say (for
example) that stream open and close events are unobservable by an
attacker watching the client, we tend to say that the attacker can't
tell when streams open and close.

(This is my sense from skimming and grepping our recent design
documentation; it may be that I'm a bit off.  Also, again, I'm not
suggesting that our practice is better than the proposed
terminology--just that it seems to be what we're doing.)

 [...]

 [...]
> Btw, I searched through the Tor documents and couldn't really find a definition.

I think the closest you'd find might be in a discussion of guard
nodes.  But I don't think we ever came up with a good formal
definition.

> Could you provide an example?

Sure. Take a session on a website.  The user's browser might request
resources from a number of different hosts, and might do so not only
for one but for several pages.  Nonetheless, it might make sense to
treat all the TCP connections as part of a single "session", since
each is already linked to all the rest semantically.

For a more trivial example, suppose a user is logging in to a service
pseudonymously.  Given this behavior, there's no point to try to make
different logins to the same pseudonymous account unlinkable by the
service: the service can already link them  through their use of the
same pseudonym.

> Is there a paper you could recommend to learn more about this aspect?

I'd check out the findings from the EFF panopticlick project for
recent results in identifying web browsers by header.  For older
results, I'll need to look around a bit. Window size alone isn't
enough to split off traffic by users (since people resize windows) and
isn't enough to isolate users (since lots of people can share a single
window size), but it helps plenty with statistical linking.

cheers,
-- 
Nick