Subject: [ietf-privacy] Comment: 'Privacy Considerations for Internet Protocols'

From: Dean Willis <[email-masked]>
Date: Mon, 11 Feb 2013 12:10:33 -0600

There's also a second aspect of "identifiability" relating to "traffic analysis" that I think may not be well-developed, and perhaps there's a better term for the concept. Can a given packet or flow of packets intercepted by an intermediary be examined to tell the intermediary what kind of traffic is present, or even what protocol is being used? One might consider this as part of "traffic analysis", but it might be useful to give specific guidance beyond "use TOR."

For example, does the protocol used a fixed token at a fixed offset within the packet (such as a protocol number) to indicate the protocol of the packet? Does it use constant data packet sizes and timing that indicate a real-time flow as opposed to a file transfer?  One might consider this "unlink ability at the packet level", but I suspect it's subtly different from the primary usage of unlink ability.

Another undeveloped concept is how does the protocol in question contribute to the privacy of other protocols simply by being used. For example, if we have lots of different protocols that have similar entropy levels and lack distinguishing marks, it's harder for an intermediary to guess which type a particular packet is. We're also missing the concept of entropy (for which "more" is generally "better", from a privacy perspective) from the whole discussion.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Feb 2013 12:01:09 -0800

On 11 February 2013 10:10, Dean Willis <[email-masked]> wrote:
> Does it use constant data packet sizes and timing that indicate a real-time flow as opposed to a file transfer?

I know that this is a real technique that has been used to detect
real-time flows, even though the flows were entirely encrypted were
presumably resistant to many other ways of identifying their type.

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 23 Feb 2013 08:27:53 -0500

Hi Dean,

On Feb 11, 2013, at 1:10 PM, Dean Willis wrote:

> 
> There's also a second aspect of "identifiability" relating to "traffic analysis" that I think may not be well-developed, and perhaps there's a better term for the concept. Can a given packet or flow of packets intercepted by an intermediary be examined to tell the intermediary what kind of traffic is present, or even what protocol is being used?

Agreed that there is more to be said about this. I suggest the following update to the definition of traffic analysis:

OLD:
$ Traffic Analysis:   The inference of information from observation
      of traffic flows (presence, absence, amount, direction, and
      frequency).  See [RFC4949].

NEW:
$ Traffic Analysis:   The inference of information from observation
      of traffic flows (presence, absence, amount, direction, timing, packet size, packet composition, and/or
      frequency), even if flows are encrypted.  See [RFC4949].

I also suggest adding this as a second paragraph in 4.1.1:

Surveillance can impact privacy even if the individuals being surveilled are not identifiable or if their communications are encrypted. For example, an observer or eavesdropper that conducts traffic analysis may be able to determine what type of traffic is present (real-time communications or bulk file transfers, for example) or which protocols are in use even if the observed communications are encrypted or the communicants are unidentifiable. Protocols that use predictable packet sizes or timing or include fixed tokens at predictable offsets within a packet can facilitate this kind of surveillance, which can adversely affect the individuals involved (for example, by having some of their communications blocked or redirected).

Note that there is also some discussion of this in section 5.3.

> One might consider this as part of "traffic analysis", but it might be useful to give specific guidance beyond "use TOR."
> 

So the question is: what do we want to recommend to protocol developers? We could express a preference for randomized packet sizes, token locations, and inter-packet timing, but it seems like we would need some discussion of how to judge when such measures are appropriate (given that gazillions of existing protocols are in wide use and don't do those things). Also, we would need to address the complexity that this introduces into implementation logic. And what sort of workable recommendations are there for how developers can harmonize their own protocols' entropy levels with all of the other protocols out there? I agree that these are good goals, but in this doc we're trying to be as concrete as possible about how your average IETFer should be designing protocols.

Alissa

---

From: SM <[email-masked]>
Date: Sun, 24 Feb 2013 08:25:51 -0800

Hi Alissa,
At 09:10 23-02-2013, Alissa Cooper wrote:
>I'm not quite sure what you are recommending here, but we have had 
>conversations in the IAB privacy program about moving the guidance 
>part up, or otherwise trying to make the focus on the guidance piece 
>more prominent. The difficulty is that there is a broad range in the 
>extent to which potential readers are familiar with privacy 
>concepts, so jumping straight into the guidance would not be 
>appropriate for some portion of the audience. If you have concrete 
>suggestions for how to simplify, those would be helpful.

 From Section 1:

   "Privacy is a complicated concept with a rich history that spans many
    disciplines."

The draft starts by saying that it is a complicated concept.  It then 
tries to fit in "data and "personal data".  It then goes into data 
and analysis, identifiability and then communication models.  I think 
that the problem stems from trying to cover the major points of all 
the authors.

The threat model is too broad, or rather, it tries to be exhaustive.

I suggest removing:

   "[RFC3552] provides detailed guidance to protocol designers about both
    how to consider security as part of protocol design and how to inform
    readers of protocol specifications about security issues.  This
    document intends to provide a similar set of guidance for considering
    privacy in protocol design."

Start with the Introduction.  Move Section 6 after by introducing the 
reader to scope.  In Section 6:

   "Transparency of data collection and use -- often effectuated through
    user interface design -- is normally a key factor in determining the
    privacy impact of a system.  Although most IETF activities do not
    involve standardizing user interfaces or user-facing communications,
    in some cases understanding expected user interactions can be
    important for protocol design.  Unexpected user behavior may have an
    adverse impact on security and/or privacy."

User interface is out of scope. :-)  I suggest not saying anything 
about it.  Transparency of data collection takes us into issues which 
are generally discussed outside the IETF.  I'll say remove this for now.

Section 3 is about the communication model.

   "To understand attacks in the privacy-harm sense, it is helpful to
    consider the overall communication architecture and different actors'
    roles within it."

It's not an attack on privacy.  To say it differently, anything "I do 
not like can be classified as an attack.

The draft discusses the communication model (second paragraph).  The 
model is supposed to, by default, "protect" privacy.  The goal is 
privacy protection.

   'As [RFC3552] explains, "we assume that the end-systems engaging in a
    protocol exchange have not However, by its nature privacy
    analysis requires questioning this assumption since systems are often
    compromised for the purpose of obtaining personal data.'

This might have to be discussed one of these days.  For now, some 
basic assumptions are needed.  Either we trust the end or else there 
is one more problem to solve.

Section 4 is about privacy threats.  I would leave it there or else I 
have to figure out what to do about the mitigation section.

   "Data minimization mitigates the following threats: surveillance,
    stored data compromise, correlation, identification, secondary use,
    disclosure."

You have some major points here.  Thinking aloud, the existing 
Section 4.2 can come after that.

There is the concept of anonymity after that.  I suggest keeping it 
as it fits within the subject.  Don't spend too much time on it as it 
is well-known that most people would block 
[email-masked].  I guess that you could use "property of 
an individual" and identity to discuss about this.

   "By providing proper security protection the following threats can be
    mitigated: surveillance, stored data compromise, misattribution,
    secondary use, disclosure, intrusion"

The draft repeats some points from a security perspective.  The commonality is:

   (a) stored data compromise

   (b) surveillance

   (c) disclosure

   (d) secondary use

There is already a BCP for security.  It's easier to let that BCP fix 
what it can.  This is where I would look into how all this fits 
within the communication model.  If the network isn't providing data 
storage that point is out of scope.  You are already doing data 
minimization.  That's the most you can do.

Section 7 is about guidelines.  It fits in the flow (of text).  In Section 7.4:

   "Does the protocol make trade-offs between privacy
    and usability, privacy and efficiency, privacy and
    implementability, or privacy and other design goals?"

It's not a good idea to get into that.  :-)  The following was from 
draft-ietf-appsawg-webfinger-09:

   "WebFinger server MUST NOT be used to provide any personal information
    to any party unless explicitly or implicitly authorized by the person
    whose information is being shared. Implicit authorization can be
    determined by the user's voluntary utilization of a service as
    defined by that service's relevant terms of use or published privacy
    policy."

That's where privacy will end once "we" get into trade-offs.  You may 
have noticed that the "MUST NOT" is violated.

Section 8 could be moved to an appendix.

If you decide to do the above you still have to do an overall pass of 
the draft for consistency.  I would have to generate an I-D and go 
through the text to see whether what I suggested makes any sense.

BTW, the draft has the following:

   "the thinking that should go into the design of a protocol when considering
    privacy as a first principle"

It's an interesting point.  You could use that to get to "privacy 
analysis".  You can then drop "privacy threats".  Basically, you are 
advising the reader analysis whether he/she has followed that 
principle to protect privacy.

Regards,
-sm

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 24 Feb 2013 21:13:01 +0200

Hi SM, 

let me just pick a few points: 

On Feb 24, 2013, at 6:25 PM, SM wrote:

>> I'm not quite sure what you are recommending here, but we have had conversations in the IAB privacy program about moving the guidance part up, or otherwise trying to make the focus on the guidance piece more prominent. The difficulty is that there is a broad range in the extent to which potential readers are familiar with privacy concepts, so jumping straight into the guidance would not be appropriate for some portion of the audience. If you have concrete suggestions for how to simplify, those would be helpful.
> 
> From Section 1:
> 
> The draft starts by saying that it is a complicated concept.

In order to address this comment we could either 
a) change the meaning of the sentence. For example, we could come to the conclusion that privacy is not that complicated after all. 
b) we could delete the sentence, or 
c) explain a bit more why it is complicated. 

I just googled for "privacy complicated concept" and found this link from Stanford: http://plato.stanford.edu/entries/privacy/
There it says: 
'
Discussion of the concept is complicated by the fact that privacy appears to be something we value to provide a sphere within which we can be free from interference by others, and yet it also appears to function negatively, as the cloak under which one can hide domination, degradation, or physical harm to women and others.
"
When I look at the Google search results it seems that it is also a complicated concept for others. One additional reason why it is even more complicated for us is since there is not such a rich experience in the technical community with designing privacy into protocols. That does not mean that I think other disciplines are easy.

> It then tries to fit in "data and "personal data".  It then goes into data and analysis, identifiability and then communication models.  I think that the problem stems from trying to cover the major points of all the authors.

Why is this structure a problem? 

These are core concept in privacy and they have to be explained somewhere. For example, whether something is personal data or not determines whether the guidelines apply. Not all protocols deal with personal data. You can essentially stop reading if you find out that your protocol has nothing to do with personal data. 

When we talk about personal data then the concept of identifiability is certainly something that jumps into a discussion next.

> The threat model is too broad, or rather, it tries to be exhaustive.

In general, the threat model is an extension of RFC 3552.
The list of threats we have added after feedback from others that we need to be a bit more specific about the threats in the Internet protocol context. The available literature often talks about privacy threats without making the distinction between the real of Internet protocol engineering and what deployments impact. 

So, what threats should be skipped in your opinion? 

> Start with the Introduction.  Move Section 6 after by introducing the reader to scope.  In Section 6:
> 
> User interface is out of scope. :-)  I suggest not saying anything about it.

It is not that simple. Just because we do not standardize user interfaces does not mean they are not important. 

I guess we both agree that the interaction of the user with the system is important (not only for privacy reasons). Just as an example from an IETF working group charter: 

"
7. Descriptions of usability and user-interface concerns related to this 
work (informational).
"
The reason it is there is because of the subtle impact of the AAA architecture on the user interaction. If you, for example, use a Web SSO mechanism then you get a permission dialog presented from the IdP before you release your personal data to the relying party. The AAA architecture is, however, different in the type of communication interaction and therefore such interaction between the IdP and the user is relayed through the RP only through a standardized protocol (EAP; not HTTP/HTML/JavaScript). 

While we cannot present super-long stories for every aspect in the document we are still planning to write a few long example documents (IPv6, for example, is one of them). 

>  Transparency of data collection takes us into issues which are generally discussed outside the IETF.  I'll say remove this for now.

I believe there is value in outlining what is typically part of the work in the IETF and what isn't. Not everyone who reads our document is familiar with the detailed scope of our work (which btw changes over time). 

I do believe it is important to say where the boundaries of the IETF work are and to state them because otherwise the next person shows up and says that you have forgotten X, Y, and Z just because we deleted it earlier due to your comments. 

Ciao
Hannes

---

From: SM <[email-masked]>
Date: Sun, 24 Feb 2013 13:45:39 -0800

Hi Hannes,
>In order to address this comment we could either

To keep matters easy I'll say that my comments have been addressed.

>
>a) change the meaning of the sentence. For example, we could come to 
>the conclusion that privacy is not that complicated after all.
>I just googled for "privacy complicated concept" and found this link 
>from Stanford: http://plato.stanford.edu/entries/privacy/
>There it says:
>'
>Discussion of the concept is complicated by the fact that privacy 
>appears to be something we value to provide a sphere within which we 
>can be free from interference by others, and yet it also appears to 
>function negatively, as the cloak under which one can hide 
>domination, degradation, or physical harm to women and others.
>"
>When I look at the Google search results it seems that it is also a 
>complicated concept for others. One additional reason why it is even 
>more complicated for us is since there is not such a rich experience 
>in the technical community with designing privacy into protocols. 
>That does not mean that I think other disciplines are easy.

I agree that it is complicated.  As you mentioned above, there isn't 
a rich experience in the technical community.  Another reason why it 
is complicated for us is that we don't usually deal with social issues.

I get the written version of "blank stares" when I ask whether a 
draft raises privacy concerns.  Frankly, it is unfair to ask an 
author to address such concerns when there is very little material to 
work from.  How can "we" make that easier?  Well, there is this IAB 
document.  The problem (as I see it) is that if I tell people that it 
is a complicated concept, they will gloss over the concerns.  I am 
not telling them that it is easy.  What I can say is that the topic 
has been made accessible through an IAB document (the draft).

>Why is this structure a problem?

I'll use RFC 6574 as an example.  The document is easy to read.  In 
my opinion it should be accessible to the average reader.  The design 
considerations are clearly laid out.  I read RFC 5218 and I came to 
the same conclusion.

It's somewhat difficult for me to follow the flow of ideas.  I would 
not have noticed that if I didn't step back from the previous 
revisions before reading the latest revision.  It's not that the 
draft is bad; it can be improved.  Three of the authors are familiar 
with the IAB style.  I suggest using that style.  It's better than 
the IETF style. :-)

>These are core concept in privacy and they have to be explained 
>somewhere. For example, whether something is personal data or not 
>determines whether the guidelines apply. Not all protocols deal with 
>personal data. You can essentially stop reading if you find out that 
>your protocol has nothing to do with personal data.
>
>When we talk about personal data then the concept of identifiability 
>is certainly something that jumps into a discussion next.

Yes.

I don't want the reader to stop reading as he/she will ignore 
stuff.  I don't want the reader to jump to the guidelines section 
without understanding the explanations in the draft.  I cannot stop 
anyone from doing that.  However, if I make it easier, some people 
might not do that.

Now, the problem is that the core concept has to be explained.  The 
linkage with the protocol aspect has to be crisp and clear.

>The list of threats we have added after feedback from others that we 
>need to be a bit more specific about the threats in the Internet 
>protocol context. The available literature often talks about privacy 
>threats without making the distinction between the real of Internet 
>protocol engineering and what deployments impact.
>

Difficult question. :-)

Thinking aloud, there isn't a compelling reason for privacy to be an 
extension of RFC 3552.  Maybe that's what making the work more 
complicated.  If there is a concern about confidentiality 
(protocol-wise) it is up to the security folks to resolve that.  The 
privacy angle is different.  Data minimalization, for example, is 
applied even if there isn't an adversary to intercept the information.

I'll react quickly to the question.  Surveillance, for example, is 
something for the security folks to resolve. :-)  The IETF already 
has a policy about wiretapping.  Stored data compromise is out of scope.

 From the Misattribution Section:

   "This threat can be mitigated by using identity management mechanisms
    with proper forms of authentication (ideally with cryptographic
    properties) so that actions can be attributed uniquely to an
    individual to provide the basis for accountability without generating
    false-positives."

You end up having to reconcile accountability and anonymity.  From a 
security point of view, you want to fingerprint everybody so that you 
can identify the person you dislike and send him/her to jail.  From a 
privacy point of view, you want a person to be able to communicate freely.

I'll use NEA as an example.  RFC 5209 has some material about 
privacy.  There is even an implementer considerations section.  In 
the IETF "we" talk about end-points.  The user aspect (privacy) is 
one step after that.  It's not a technological issue.

>It is not that simple. Just because we do not standardize user 
>interfaces does not mean they are not important.

Yes.

>I guess we both agree that the interaction of the user with the 
>system is important (not only for privacy reasons). Just as an 
>example from an IETF working group charter:
>
>"
>The reason it is there is because of the subtle impact of the AAA 
>architecture on the user interaction. If you, for example, use a Web 
>SSO mechanism then you get a permission dialog presented from the 
>IdP before you release your personal data to the relying party. The 
>AAA architecture is, however, different in the type of communication 
>interaction and therefore such interaction between the IdP and the 
>user is relayed through the RP only through a standardized protocol 
>(EAP; not HTTP/HTML/JavaScript).

Ok, you'll need the user interface angle then.

>While we cannot present super-long stories for every aspect in the 
>document we are still planning to write a few long example documents 
>(IPv6, for example, is one of them).

Ok.

>I believe there is value in outlining what is typically part of the 
>work in the IETF and what isn't. Not everyone who reads our document 
>is familiar with the detailed scope of our work (which btw changes over time).

The problem is that there is value in keeping most, if not all, of 
the draft.  And that takes us back to complicated concept.

>I do believe it is important to say where the boundaries of the IETF 
>work are and to state them because otherwise the next person shows 
>up and says that you have forgotten X, Y, and Z just because we 
>deleted it earlier due to your comments.

This is interesting.  Maybe you could have the X, Y, and Z together 
in a section.

Regards,
-sm

---

From: Claudia Diaz <[email-masked]>
Date: Mon, 25 Feb 2013 22:15:03 +0100

Hi, 

>      frequency), even if flows are encrypted.  See [RFC4949].

I would add to these "identities of the communicating parties" and "location". 

> You end up having to reconcile accountability and anonymity.  From a security point of view, you want to fingerprint everybody so that you can identify the person you dislike and send him/her to jail.  From a privacy point of view, you want a person to be able to communicate freely.

The difference between "security" and "privacy" is, imho, dependent on the stakeholder whose security is to be protected, and not to the nature of the "security property" (accountability, anonymity). For example, we would call it "security" (even "national security") if the entity "communicating freely" was a military organization instead of an individual. 

So, if your perspective is the one of the entity in a position to perform surveillance (with the power to act based on the collected intelligence), then "security" tends to be equated with "accountability" (which often relies on some form of surveillance). If on the other hand your perspective is that of the entity being potentially subject to surveillance, then security would be closer to "anonymity". 

If that entity is a gov/commercial organization, then "security" is the term likely to be used for the properties you want to achieve, while for those same properties "privacy" is the usual term when the entity is a private individual. 

Best regards
Claudia

PS: wishing i had more time to look into the full document and all the discussions.

---

From: SM <[email-masked]>
Date: Tue, 26 Feb 2013 00:45:38 -0800

Hi Claudia,
At 13:15 25-02-2013, Claudia Diaz wrote:
>If that entity is a gov/commercial organization, then "security" is 
>the term likely to be used for the properties you want to achieve, 
>while for those same properties "privacy" is the usual term when the 
>entity is a private individual.

There is currently a security considerations section in every IETF 
RFC.  The draft recommends having a privacy considerations section 
too.  The question which can arise is in which section the 
perspective should be covered.  In other words it is about how to 
disambiguate between security and privacy.

Regards,
-sm

---

From: Claudia Diaz <[email-masked]>
Date: Tue, 26 Feb 2013 23:11:28 +0100

On 26 Feb 2013, at 09:45:38, SM wrote:

> There is currently a security considerations section in every IETF RFC.  The draft recommends having a privacy considerations section too.  The question which can arise is in which section the perspective should be covered.  In other words it is about how to disambiguate between security and privacy.

It's a tough one: I am not sure you can fully disambiguate the two terms if you are considering general-purpose protocols. 

To me, given the way the term "privacy" is used in computer security (not in social sciences or in everyday language), the clearest disambiguation is that privacy is "security for private individuals". I do not think there are differences in the "essence" of what it means to provide security/privacy, but rather in the stakeholder (individual or organization) to whom we want to guarantee the security/privacy properties. 

Some examples: 

1) A has confidential data and B gains unauthorized access to the data

- If the data is internal to an organization (e.g., the strategy of a corporation, or military plans), then we talk about a "security breach"
- If the data relates to individuals (e.g., health records), then we talk about a "privacy breach"

2) A wants to communicate with B anonymously with respect to an eavesdropper C

- If A and B are organizations (e.g., two military units in foreign territory), then we talk about communications "security" 
- If A and B are individuals, then we talk about "privacy" 

3) A wants to publish/access information and B prevents A from doing so. 

- If A is an organization, then we talk about "denial of service", and we relate it to "security". 
- If A is an individual (eg, a blogger, or someone trying to access Facebook), then we call it "censorship" and we relate it to "privacy". 

4) Even if we think about deploying surveillance, the distinctions would still apply, I think. 

- Law enforcement being able to locate and take down child pornography is "security"
- Imagine an application for private individuals that would search the web looking for publicly available pictures of themselves (so they can ask for the pictures to be removed). We would say that this is an application for "privacy".

---

From: David Singer <[email-masked]>
Date: Tue, 26 Feb 2013 14:19:15 -0800

> It's a tough one: I am not sure you can fully disambiguate the two terms if you are considering general-purpose protocols. 

For the purposes of debate, I am going to try.

Security problem: something unintended happened which gave an attacker/opponent access to data, systems, or capability which was not an expected part of the identified system/protocol.

Privacy problem: operation of the system/protocol gives undesirable exposure of private information not strictly needed for the operation desired. 

If you combine them, then indeed the privacy problem may well get worse.

So, for example, the fact that on the internet your IP address is exposed as part of the protocol also gives your respondent probable knowledge of your location, and hence time of day.  No rules were broken to see your IP address or draw conclusions from it - there was no 'break-in' or security hole that was taken advantage of.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 26 Feb 2013 15:36:26 -0700

This document only concerns the privacy of individuals (as is made fairly clear in sections 1 and 2, although perhaps it is not explicit enough). Does that help?

Alissa

---

From: Claudia Diaz <[email-masked]>
Date: Tue, 26 Feb 2013 23:42:53 +0100

> So, for example, the fact that on the internet your IP address is exposed as part of the protocol also gives your respondent probable knowledge of your location, and hence time of day.  No rules we…

That's an interesting distinction. Translating it to concrete scenarios would make us however have to change how we usually use the terms. This can be counterintuitive in some cases: 

- If I browse to a website and my IP is exposed, then it is a privacy problem. If I browse to the same website over Tor and my IP is exposed because Tor is attacked, then it is a security problem. 

- If the passwords to access the confidential information at the embassy are sent in clear (because nobody bothered to encrypt them), it is a privacy problem, and not a security problem. If someone manages to get my facebook password, then it is a security problem, and not a privacy problem (because it was not exposed by default). 

- If the gov listens to my encrypted conversations (eg, by reconstructing the conversation from the traffic), it is a security problem. If the minister of interior talks over an unencrypted line about his plans to catch terrorists, then it is a privacy problem.

---

From: David Singer <[email-masked]>
Date: Tue, 26 Feb 2013 15:08:05 -0800

> - If I browse to a website and my IP is exposed, then it is a privacy problem. If I browse to the same website over Tor and my IP is exposed because Tor is attacked, then it is a security problem. 

To be precise, there was a security breach (your IP address was exposed when the design of the protocol and your expectations said it would not be), and that resulted in a privacy problem.  Many security problems indeed result in privacy issues (not surprisingly).

> - If the passwords to access the confidential information at the embassy are sent in clear (because nobody bothered to encrypt them), it is a privacy problem, and not a security problem.

Agreed.  The protocol was being operated in its expected way, and no protocol violation or break-in was needed. (It was the wrong protocol to use.)
 
> If someone manages to get my facebook password, then it is a security problem, and not a privacy problem (because it was not exposed by default). 

If they broke in, they took advantage of a security issue of some sort. The result was, again, a privacy violation.

> - If the gov listens to my encrypted conversations (eg, by reconstructing the conversation from the traffic), it is a security problem. If the minister of interior talks over an unencrypted line ab…

I think we are on the same page.  Security breaches often result in privacy problems, but not always, and privacy issues don't always happen as a result of security breaches -- and it is the ones that don't that I think we should focus on.  (Once the 'lock is broken' we can't say much about privacy, I fear -- we're into limiting damage).

The famous CSS link-visited issue is a privacy issue, pure and simple.  It's possible to write a script that finds out what links a user has recently visited, using public APIs in their intended way.

Exploring what the privacy implications of using a specification "in its normal way" I think is way overdue.

We can *also* think about specifying prudent steps to take such that if there is *also* a security break-in, the resulting privacy impact is minimized (e.g. "keep as little private data as you for only as long as you need it, so if you have a data loss/leak/break-in, the impact is minimized").  But that's secondary.

David Singer

---

From: Eric Burger <[email-masked]>
Date: Tue, 26 Feb 2013 15:56:43 -0800

So what if we just said Security Considerations must include what some people call privacy considerations? If we cannot agree on a concise definition of security vs. privacy, what is the typical draft author going to do?

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>

On Feb 26, 2013, at 3:08 PM, David Singer <[email-masked]> wrote:

> _______________________________________________
> ietf-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: Claudia Diaz <[email-masked]>
Date: Wed, 27 Feb 2013 14:07:32 +0100

Hi David, 

this distinction could make sense. I guess one issue to consider is to what extent the adversary needs to make an effort to break the security of the system for the issue to be considered a security breach. For example, if there are protocols with known vulnerabilities that have not been fixed and that are trivial to exploit, is that a security or a privacy breach? There may be border cases for which it is difficult to draw the line. 

Regards
Claudia

---

From: SM <[email-masked]>
Date: Thu, 28 Feb 2013 16:22:12 -0800

Hi Eric,
At 15:56 26-02-2013, Eric Burger wrote:
>So what if we just said Security Considerations must include what 
>some people call privacy considerations? If we cannot agree on a 
>concise definition of security vs. privacy, what is the typical 
>draft author going to do?

Security Considerations can be stuff like "MUST implement 
TLS".  Privacy considerations would be about the decision of an individual.

I agree that it make matters difficult for the typical draft 
author.  The person will likely copy and paste stuff from other RFCs.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Thu, 28 Feb 2013 16:22:12 -0800

Hi Eric,

Regards,
-sm

---

From: SM <[email-masked]>
Date: Thu, 28 Feb 2013 16:34:41 -0800

Hi Claudia,
At 14:42 26-02-2013, Claudia Diaz wrote:
>That's an interesting distinction. Translating it to concrete 
>scenarios would make us however have to change how we usually use 
>the terms. This can be counterintuitive in some cases:
>
>- If I browse to a website and my IP is exposed, then it is a 
>privacy problem. If I browse to the same website over Tor and my IP 
>is exposed because Tor is attacked, then it is a security problem.

Ok.

>- If the passwords to access the confidential information at the 
>embassy are sent in clear (because nobody bothered to encrypt them), 
>it is a privacy problem, and not a

It's a security problem.

>- If the gov listens to my encrypted conversations (eg, by 
>reconstructing the conversation from the traffic), it is a security 
>problem. If the minister of interior talks over an unencrypted line 
>about his plans to catch terrorists, then it is a privacy problem.

The last sentence is about a security problem.

Regards,
-sm

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Feb 2013 17:07:21 -0800

I think the point is we have a clue, and we disagree. What is a person without a clue to do?

On Feb 28, 2013, at 4:34 PM, SM <[email-masked]> wrote:

>> - If the passwords to access the confidential information at the embassy are sent in clear (because nobody bothered to encrypt them), it is a privacy problem, and not a
> 
> It's a security problem.
>

---

From: David Singer <[email-masked]>
Date: Thu, 28 Feb 2013 17:14:45 -0800

inline…

> I think the point is we have a clue, and we disagree. What is a person without a clue to do?

I think you're being a bit brief here.  It's not a security problem with the design of the protocol; if it carries data in the clear, it never pretended to be secure.  It's a problem that it was the wrong protocol to be used, for sure.  We're concerned about intrinsic security and privacy problems in our specifications, not the mis-use of them (though we can warn, I guess).

>> The last sentence is about a security problem.

ditto.  There was nothing wrong with the design of the unencrypted line; it was the wrong 'protocol' to use.

David Singer

---

From: SM <[email-masked]>
Date: Thu, 28 Feb 2013 17:39:37 -0800

>person without a clue to do?

The person can convince Alissa and Hannes to suggest text. :-)

At 17:14 28-02-2013, David Singer wrote:
>I think you're being a bit brief here.  It's not a security problem 
>with the design of the protocol; if it carries data in the clear, it 
>never pretended to be secure.  It's a problem that it was the wrong 
>protocol to be used, for sure.  We're concerned about intrinsic 
>security and privacy problems in our specifications, not the mis-use 
>of them (though we can warn, I guess).

Sorry about that.  There is usually a security policy.  This is not 
part of the protocol; it's about what security measures should be taken.

>ditto.  There was nothing wrong with the design of the unencrypted 
>line; it was the wrong 'protocol' to use.

Yes.  The issue is related to information classification and disclosure.

BTW, the cases can be argued both ways.  Given that privacy is 
complex it is easier to explain some points in terms of security.

Regards,
-sm

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Feb 2013 18:09:49 -0800

Isn't the problem that when the protocol was written (thinking in the abstract), no one knew it was going to be used for foo, and foo did not have the proper security properties? You are right, it is almost a policy problem, not a technology problem, that the wrong protocol was chosen. I am not sure we can anticipate all uses of a protocol and warn against stupidity.

On Feb 28, 2013, at 5:39 PM, SM <[email-masked]> wrote:

> Sorry about that.  There is usually a security policy.  This is not part of the protocol; it's about what security measures should be taken.
> 
> BTW, the cases can be argued both ways.  Given that privacy is complex it is easier to explain some points in terms of security.
> 
> Regards,
> -sm

---

From: David Singer <[email-masked]>
Date: Thu, 28 Feb 2013 18:25:23 -0800

> Isn't the problem that when the protocol was written (thinking in the abstract), no one knew it was going to be used for foo, and foo did not have the proper security properties? You are right, it…

we can't, you are right.  A single sentence in the protocol "this protocol is not intrinsically secure; if security is needed, use, or layer on, a different protocol" might be enough.

in 'privacy considerations' I think we need to explore the privacy consequences of using protocols 'appropriately'.  And there are, and it's no longer OK not to worry about them as we design protocols.

David Singer

---

From: SM <[email-masked]>
Date: Thu, 28 Feb 2013 21:48:00 -0800

At 18:09 28-02-2013, Eric Burger wrote:
>Isn't the problem that when the protocol was written (thinking in 
>the abstract), no one knew it was going to be used for foo, and foo 
>did not have the proper security properties? You are right, it is 
>almost a policy problem, not a technology problem, that
>  the wrong protocol was chosen. I am not sure we can anticipate all 
> uses of a protocol and warn against stupidity.

Yes.

At 18:25 28-02-2013, David Singer wrote:
>in 'privacy considerations' I think we need to explore the privacy 
>consequences of using protocols 'appropriately'.  And there are, and 
>it's no longer OK not to worry about them as we design protocols.

Yes.

Regards,
-sm