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

From: S Moonesamy <[email-masked]>
Date: Sat, 14 Sep 2013 08:28:08 -0700

Hello,

The initial version of draft-moonesamy-privacy-identifiers was 
submitted over a year ago.  There was some discussion about the draft 
on this mailing list.  I submitted 
draft-moonesamy-privacy-identifiers-01 ( 
http://tools.ietf.org/html/draft-moonesamy-privacy-identifiers-01 ).

Anyone who feels strongly about privacy might find it the main change 
(first paragraph of Section 1) of some interest as it is a good start 
to understand the relation between privacy and secrecy.

I added a reference to RFC 6973 as it may be useful for authors 
writing IETF specifications.

The draft restricts to a brief discussion of privacy and 
identifiers.  The intent is to keep it easy for the reader and 
encourage the person to think about identifiers from a privacy 
perspective.  The draft does not focus on the technical aspects so as 
to be accessible to a technical and non-technical audience.

I would appreciate comments about the draft.

Regards,
S. Moonesamy

---

From: <[email-masked]>
Date: Tue, 17 Sep 2013 13:56:29 +0200

Hi SM,

Thank you for updating the draft.

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.

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.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]]
>De la part de S Moonesamy
>Envoyé : samedi 14 septembre 2013 17:28
>À : [email-masked]
>Objet : [ietf-privacy] Privacy and Identifiers - draft-moonesamy-privacy-
>identifiers-01
>
>Hello,
>
>_______________________________________________
>ietf-privacy mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 17 Sep 2013 10:42:23 -0700

Hi Med,
At 04:56 17-09-2013, [email-masked] wrote:
>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:
>* 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/

---

From: Avri Doria <[email-masked]>
Date: Tue, 17 Sep 2013 14:24:44 -0400

On 17 Sep 2013, at 07:56, <[email-masked]> <[email-masked]> wrote:

> is, from a privacy perspective, there is no justification for it

I think it is an extension of the principle, that information should only used for the purpose for which it was collected, or in this case included in the packet.  In order to make privacy abuse more difficult each layer should be as privacy enhancing as possible.

While it is true that some information needs to be sent to another layer to support that layers basic functions, this should be kept to a minimum needed for functionality.  and and I can't think of a reason ever for information to be used at layer+-2 unless specifically pased by layer+-1.

avri