Re: [ietf-privacy] Privacy and Identifiers - draft-moonesamy-privacy-identifiers-01

[S Moonesamy <[e-mail]>]

Hi Med,
At 04:56 17-09-2013, [e-mail] wrote:
>One comment I have when reading this reco from your draft:
>
>       It is recommended that an identifier be used at the layer at which
>       its functionality is necessary for communication to be
>       established.
>
>is, from a privacy perspective, there is no justification for it. If 
>the information is present in the packet, does it really matter if 
>it is used in other layers? Why reusing that info will impact the 
>privacy? Take the example of TCP that use the IP address for the 
>pseudo header checksum, SIP, SDP, etc. If you have in mind 
>particular identifiers, it would be valuable to explicit them rather 
>than having a generic statement.

The problem is secondary use (see RFC 6973 Section 5.2.3) and consent 
[1].  The draft argues that consent is implicit if the information is 
necessary for communication.  If it is necessary to send out the IP 
address in the TCP session, that does not mean that the protocol at a 
higher layer can take it and put it in a header field.  As an 
example, please see Section 8.2 and 8.2 of 
draft-ietf-appsawg-http-forwarded-10.

 From a privacy perspective I can find out your approximate location 
the source IP address used for your SIP call.  There are times when 
that can be embarrassing, e.g. you told your manager that you are 
calling from work while the source IP address points to another 
location.  Let's say that we have to document the privacy 
implications in our document.  The reuse cases will be more work for 
us as we have to think of more possibilities.  The way to avoid that 
is apply some form of layering when we tackle privacy.

The examples in Section 4 (of the draft) were chosen as the related 
specifications explain what these identifiers are above.  There isn't 
any explanation in plain English for identifiers used in other 
specifications.  I could take the RFC 6973 approach and write a long 
document.  My guess is that people won't read it. :-)  The approach I 
adopted was to keep it simple.  A generic statement can be argued 
both ways.  For example, you can argue that the identifier is 
necessary at the higher layer without having to ask the user for 
consent.  I used "recommendation" instead of "requirement" so as not 
to impose constraints.

>If we take the example of an IP address as an identifier, even if it 
>is revealed in various layers, this does not mean that one single 
>individual/user is associated with that identifier. Take the example 
>of multiple machines behind the same CPE, or multiple subscribers 
>behind the same CGN, etc. Nevertheless:
>* the configuration of a browser may be used easily to track user 
>(e.g., https://panopticlick.eff.org/)
>* some application headers (e.g., referer) may contribute to ease 
>the correlation between many pieces of information (e.g., a web 
>email account and a social networking account for instance)
>
>Discussing issues related to correlating information leaked by 
>applications would be useful to record in this document.

I commented about a draft recently (see 
http://www.ietf.org/mail-archive/web/homenet/current/msg03100.html 
).  In a NAT scenario we cannot say that there is only one person 
behind the CPE.  The same applies to CGN.  In an IPv6 scenario we can 
narrow down (or might assume) that it is one person or device using 
the IPv6 address.  When the legislator writes the law the questions 
that he or she will ask is:

   (a) Does the IP address identify one person?

   (b) Does the IP address identify the location from which the call was made?

Note that there is some ambiguity in the questions.  The legislator 
would like to have easy answers.  This is where someone explains that 
the IP address can be used to identify the person.  For (b) the 
explanation might be that the IP address can be used to identify the 
location.  It can be lead to events such as 
http://www.tmz.com/2013/04/05/selena-gomez-swatted/

The browser sends a lot of information (re. the link you 
provided).  There are already some good questions in RFC 6973.  I 
chose not to discuss it in the draft to keep the discussion 
simple.  What I would like to see, for example, is what you did.  You 
mentioned that correlation can be a problem and you thought about 
some other problems.  I don't have the answers.  However, it is a 
step forward if you and I can talk about privacy and try and 
understand how the identifiers can be used.

Regards,
S. Moonesamy

1. 
http://www.cnil.fr/les-themes/internet-telephonie/fiche-pratique/article/ce-que-le-paquet-telecom-change-pour-les-cookies/