Re: [ietf-privacy] Privacy Considerations Document

[Hannes Tschofenig <[e-mail]>]

Hi Alissa, 

Thank you for your review and sorry for my late response.

With the early versions of the document I thought it would be helpful to
describe what privacy is. This, however, turns out to be complicated as the
literature shows. For this reason I have moved the text into the appendix
and, as you suggested, maybe it is more useful to delete it all together.

The suggestion to consider the two categories communication and information
privacy is certainly a good idea. In some sense, however, this is already
covered in the threat section (just with different words). The classical
communication security security overlap a bit with communication privacy" in
my opinion. One could probably claim that protocol designers in the IETF
already have to deal with this aspect in quite some level of detail as part
of the security considerations already.

Adding some text about the different adversaries makes sense to me.

Talking about the privacy related risks is always difficult without going
into specific examples. This also relates to the scoping question and what
can be accomplished by someone working in the IETF at best. The scoping
section tries to address this question because a typical response to
technical work on privacy is that this is more a policy topic rather than a
technological one. Also the introductory section talks about the two
extremes. These are not artificial extremes either when looking at the
research work vs. company practices.

While it may be obvious for some what the scope of the work is within the
IETF I do not believe it is shared and understood among a large number of
persons. Think about the work in the GEOPRIV working group and how often we
got the response that 'the approach does not work because the policies are
not enforced technically'.

With the discussions around the different types of documents in the IETF I
wanted to explain the different level of guidance one could give. An
architectural document can certainly say more than a document that describes
a MIME type or a single protocol.

A few words on the threat model:

Regarding the guidelines, there is certainly value to incorporate some of
the questions from draft-morris-policy-cons-00.txt.
draft-morris-policy-cons-00.txt, however, takes a very generic approach. I
believe that many protocol developers will have a hard time to answer these
questions. The two documents are clearly related but there is a considerable
difference between the two, I believe. I suspect that you mean only to
re-use those parts that relate directly to privacy rather than re-using the
wide spectrum of questions. I have copied the relevant parts to the bottom
of my mail.

I had tried to use the current guidelines in the document for a write-up of
an example privacy consideration section. I used the ABFAB architecture
document for this purpose:
http://tools.ietf.org/html/draft-lear-abfab-arch-02

I was able to apply the structure in the privacy considerations document
quite well to the ABFAB architecture draft. There are, however, some remarks
to be made as well. First, this ABFAB document is easier to deal with since
it is an architecture document. I believe discuss privacy for a protocol
document will be much more difficult. Second, ABFAB re-uses existing and
deployed protocols and therefore some challenges already exist that cannot
be fixed easily. I tried to capture them in Section 5.5 of
draft-lear-abfab-arch-02 and there weren't any questions in the privacy
consideration document focusing these aspects. I believe that they are only
applicable to a certain class of protocols.

Ciao
Hannes

PS: Copy-and-paste from draft-morris-policy-cons-00.txt:

5.3.  Monitoring or Tracking of Usage

   o  Would the Technology permit the monitoring or tracking by a Third
      Party of the use of particular content, functionality, or
      resources?

         See discussion of "Personal Privacy."

[hannes]  This question is a bit too generic to be helpful.

5.4.  Retention, Collection, or Exposure of Data

   o  Would the Technology require or permit the retention of any
      information about individual packets or communications, or
      individual End Users, either (a) beyond the conclusion of the
      immediate network or communications event, or (b) for longer than
      a reasonably brief period of time in which a communications
      "session" can be concluded?


[hannes] This is hard to answer. For example, let us take the ABFAB scenario
again. There, the work is about the AAA interaction and it is done for
authenticating a user towards a service, for authorizing the user's service
usage, and (if needed) for accounting purposes. Many of the services would
want to keep information about the previous communication attempts for
various purposes, including charging and billing, dispute resolution, fraud
prevention, statistic purposes, network planning, etc. The problem is that
none of this can be decided by the protocol designer itself in this example.


   o  Would the Technology permit the reading or writing of any file on
      an End User's computer without the explicit knowledge of the End
      User?

[hannes] This is probably a good question related to the cookie debate.
In my ABFAB example certain EAP methods may allocate state information for
the authentication and key exchange protocol to speed-up subsequent protocol
interactions. The question, however, is whether this is necessarily a bad
thing. I can think about the 3GPP-AKA algorithms, which store a temporary id
on your end system to provide passive user identity confidentiality - a
privacy feature. 

   o  Would the Technology permit or require that information other than
      location and routing information (such as, for example, personal
      information or search terms) be made a part of a URL or URI used
      for a communication?

[hannes] I am not sure I understand this question.


   o  Would the Technology permit or require that personal or
      confidential information be made available to any Third Party,
      Transit Provider, or Access Provider?

[hannes] This question is also a bit vague given all the insight we have now
regarding personal information and how easy it is to link to an individual
person with non-personal information.

         See discussion of "Personal Privacy."

5.5.  Persistent Identifiers and Anonymity

[hannes] These are good questions but largely covered already by the
guidelines in the document and supported with the terminology we have in the
privacy terminology document.

   o  Would the Technology require or permit the association of a
      persistent identifier with a particular End User, or a computer
      used by one or more End Users?

   o  Would the Technology reduce the ability of a content provider to
      provide content anonymously?

   o  Would the Technology reduce the ability of an End User to access
      content or utilize functionality anonymously?

         See discussion of "Personal Privacy."

5.6.  Access by Third Parties

[hannes] These questions relate to communication privacy. The threat model
covers it but it would probably help to be more explicit in the list of
questions.

   o  Would the Technology permit any Third Party to have access to
      packets to and from End Users without the explicit consent of the
      End Users?

   o  Would the Technology permit or require any Third Party to store
      any information about an End User, or an End User's communications
      (even with the knowledge and consent of the End User)?

         See discussions of "Personal Privacy" and "User Consent."



On 3/23/11 8:10 PM, "Alissa Cooper" <[e-mail]> wrote:

> I did a brief review of this document up to section 4.
> 
> === General comments ===
> 
> To accomplish this document's two stated goals -- to make protocol
> designers aware of privacy-related design choices and to offer
> guidance for developing privacy considerations for IETF documents -- I
> would suggest re-thinking the approach somewhat. As it stands, the
> document does not contain a concise statement of what it means to
> protect or enhance privacy. The threat model discussion gives some
> examples, but it strikes me that if this document wants to say to
> protocol designers, "privacy matters and here's how to design/document
> the privacy impact of your protocol," then it needs to say a little
> bit about what concept of "privacy" it assumes.
> 
> On the other hand, I don't think throwing the kitchen sink of privacy
> definitions/concepts in there will help. The appendix aptly
> demonstrates this.
> 
> Rather, my suggestion would be to articulate a few simple categories
> of privacy interests that individuals have and that IETF protocols may
> implicate. Stealing a few words from draft-morris-policy-cons-00, I
> think there are two types of privacy with which to concern ourselves:
> 
> -- Communications privacy: the right of individuals to control access
> to their communications
> -- Information privacy: the right of individuals to control
> information about themselves
> 
> And three types of relevant adversaries:
> 
> -- Commercial
> -- Individual
> -- Governmental
> 
> One of the key differences between communications privacy and
> information privacy has to do with identifiability -- interception of
> communications can violate a person's privacy whether or not the
> person is identified or identifiable.
> 
> The type of adversary may not matter from a protocol standpoint, but I
> think it's helpful to conceptualize the threats at the outset, e.g.,
> governments can infringe communications privacy by wiretapping,
> commercial entities can infringe information privacy by selling my
> data to the highest bidder, an individual can infringe my information
> privacy by accessing my presence or location information without my
> knowledge, etc.
> 
> I think the document needs some simple frame like this to explain what
> the threats/risks are.
> 
> The communications/information privacy breakdown also raises the
> question of whether this document needs to address communications
> privacy, or whether the existing norm that we have of documenting
> threats to confidentiality and their mitigations in the security
> considerations section of most RFCs is sufficient or nearly so.
> 
> === 1. Introduction ===
> 
> I'm not sure that most of the text here is serving its purpose. I
> don't think the three schools of thought really reflect reality, but
> even if they do, I don't think it's necessary to address the two
> narrow-minded views. Some aspects of privacy can be addressed by
> protocol designers, others can only be addressed through policy, and
> the two need to work together to provide meaningful protection. I
> don't think much more than that needs to be said.
> 
> === 2. Scope ===
> 
> Again here, there seems to be a simple basic point, which is that
> privacy can be and need be only addressed within the scope of the
> protocol being developed.  I'm not sure a whole lot more than that
> needs to be said, and it's unclear how the classification of IETF
> document types fits in (the section is almost set up as if it's going
> to say that some document types require privacy considerations while
> others don't, but then it never says that).
> 
> === 3. Threat Model ===
> 
> If the communications/information privacy split were to be used, then
> I think you could break down the threats according to which kind of
> privacy they have the potential to violate: eavesdroppers and
> intermediaries primarily affect communications privacy, whereas
> recipients (and I might also add "other recipients" or some other
> category to cover entities/individuals that obtain data from intended
> recipients) primarily affect information privacy.
> 
> In addition to notice, choice, and consent, I would add the full suite
> of fair information practices (limiting use, providing access, etc.)
> to the list of responsibilities for the recipient.
> 
> === 4. Guidelines ===
> 
> Note that the questions in this section were originally developed
> solely in response to information privacy concerns. I need to think
> about these more -- they don't really seem to make much sense in the
> context of guidance for protocol designers as is, so maybe some
> further development or combination with some of the privacy questions
> from draft-morris-policy-cons-00 would make more sense.
> 
> Alissa
> 
> On Mar 16, 2011, at 11:19 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
> 
>> Hi all,
>> 
>> We have also updated the "Privacy Considerations for Internet
>> Protocols"
>> document:
>> http://tools.ietf.org/html/draft-morris-privacy-considerations-03
>> 
>> There are still a couple of questions about the content of the
>> document,
>> including what level of background on privacy is needed for
>> engineers in
>> their work to write a privacy considerations section. For the
>> moment, I
>> have moved the historical treatment of privacy into the appendix of
>> the
>> document. The Fair Information Practices, which are listed in that
>> part
>> of the section, seem at the beginning to be essential but on the other
>> hand they do not provide helpful guidance for engineers.
>> 
>> The current approach is to focus on a list of questions that protocol
>> designers should ask themselves. Those questions are listed in Section
>> 4.
>> 
>> I have tried to apply these guidelines in my writeup of the "ABFAB
>> Architecture" document, a recently started effort in the IETF with
>> relevance to privacy:
>> http://tools.ietf.org/html/draft-lear-abfab-arch-02
>> 
>> If you have suggestions for additional guidance I would like to hear
>> them.
>> 
>> Ciao
>> Hannes
>> _______________________________________________
>> ietf-privacy mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>> 
> 
>