Re: [ietf-privacy] Privacy Considerations Document

[Alissa Cooper <[e-mail]>]

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
>