Subject: Re: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt

From: Brian Trammell <[email-masked]>
Date: Thu, 5 Feb 2015 15:09:48 +0100

hi Björn,

Thanks for the review! Comments/questions on points inline, points removed will be edited into the working document without comment.

> On 10 Jan 2015, at 02:08, Bjoern Hoehrmann <[email-masked]> wrote:
> 
> * Ted Hardie wrote:
>> The program and authors would appreciate review of
>> draft-iab-privsec-confidentiality-threat-01.txt (
>> http://www.ietf.org/id/draft-iab-privsec-confidentiality-threat-01.txt).
>> Note that the text on mitigations to these threats has been split into a
>> second document which is forthcoming.  Reviews can be sent to this list or
>> the authors.
> 
> Mostly editorial things on sections 1-3:

> In Section 2 I think the example for "Infererence" should be replaced by
> a much simpler one.

Do you have a suggestion here?

> I am not happy with using "Observation" with the specified meaning in
> this context. The word usually refers to the act, not the data, and here
> it may be easy to confuse it with, say, targeted surveillance as part of
> a justice system, perhaps especially for non-native readers. I encourage
> trying to find an alternative term.

This terminology is borrowed from the passive network measurement community, and specifically from the terminology for IPFIX/PSAMP (see RFC 7011). Unfortunately, in this space we've pretty much used all the words we could (many multiple times), so I think any change would be arbitrary. However, I'm open to suggestions for better terms.

> The definition for "Unwitting Collaborator" as though an "Unwitting
> Collaborator" is a "Collaborator". That seems incorrect to me.

How about "An entity that is a legitimate participant in a communication, and who is the source of information obtained by the attacker without the entity's consent or intention, because the attacker has exploited some technology used by the entity"?

> I do not think "Key Exfiltration" depends on the presence of a
> "collaborator". Same for "Content Exfiltration".

Without a collaborator (deliberate or unwitting), how would this be exfiltration?

> I think Section 3 would benefit from a short preface that explains, as
> the section title suggest, this is an "idealised" description, and
> explains how this is useful. Right now the section jumps right into
> describing something that is extremely implausible without qualifiers,
> and many readers might be unfamiliar with such descriptions.

The idealized attacker model was based on more or less the maximum set of capabilities you could publicly (i.e. outside the security community) ascribe to an entity performing pervasive surveillance without being accused of paranoia, before the spring of 2013. It only seems implausible *now* because of what we know and can confirm. 

I think we can make this clearer with a little text and some reorganization.

Thanks again! A new version will follow shortly.

Cheers,

Biran

> -- 
> Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
> D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
> Available for hire in Berlin (early 2015)  · http://www.websitedev.de/ 
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Brian Trammell <[email-masked]>
Date: Fri, 6 Feb 2015 12:27:54 +0100

hi Aziz,

Many thanks for your review! Anything I don't reply to from your message I'll pull directly into the -02 draft. Otherwise, comments on comments inline below:

> On 13 Jan 2015, at 21:47, Aziz Mohaisen <[email-masked]> wrote:
> 
> 
> The document provides an interesting view of the threat posed by pervasive monitoring and tries to formalize a threat model around the problem. However, the model still lacks rigor, and examples mentioned to highlight the idealized pervasive passive adversary (as defined in the document) seem to share some elements of an active attack, suggesting that this perhaps should be called a “hybrid adversary”. Most of my comments in the feedback below are on this point, and cite parts of the document where this issue is clear. This feedback also provides some typos that need be fixed (towards the end of the feedback).

I agree that the main issue raised by this review goes back to a disagreement about the meaning of "passive" and "active" as used in the document. "Passive" here is with respect to the network. Passive attacks do not change the traffic stream or the handling of the traffic stream in the network, active attacks do. Compromise of an intermediate system (whatever the layer or method) is, from the point of view of the traffic stream, passive. In this terminology, an attack only becomes active once the attacker modifies the traffic stream: MITM attacks, session hijacking and resetting, route injection, cache poisoning, etc. are all active.

I think an additional definition of "active" and "passive" in the terminology section as used in the document would clear this up.

> I hope these comments/suggestions help.
> 
> Aziz

> page 2:
> Inference should be specified to be indirect, and not just any information obtained through analysis (e.g., summary)

I'm not sure what you mean here... Inference is indirect, and is necessarily the output of analysis. Do you have a specific suggestion here?

> 
> - (Page 2-3) The word passive is somewhat misleading. Capabilities listed under the passive pervasive attack include elements where a system is compromised; surely compromising a system is an active act and not passive.

The reason to make this distinction is that it "set[s] a lower bound on the capabilities of an attacker interested in indiscriminate passive surveillance while interested in remaining undetectable." Yes, the activity of compromising the intermediate was probably "active", but from the point of view of the endpoints, it is unobservable.

> The description of the “Idealized Pervasive Passive Attacker” is a bit confusing; on the one hand, it is understood that the attacker does not actively seek to gain access to users data — by the virtue of being passive.

No, it actively seeks to gain access to users' data, and doesn't modify the user's traffic to do so.

> On the other hand, at the same time the attacker can observe data in intermediaries by compromising those intermediaries — e.g., stated in the last paragraph on page 3. Even when a vulnerability exists in such intermediaries, the adversary would have to actively use the vulnerability — by compromise, as stated towards the end of page 3 — in order to be able to observe contents in the intermediary. To this end, the definition seems to mix both active and passive attackers.
> 
> Page 6:
> - The last point in section 3.3.2. does not seem to follow the aforementioned attacker model. [In many jurisdictions, Internet Service Providers (ISPs) are required to provide identification on a case by case basis of the "owner" of a specific IP address for law enforcement purposes]  -> this does not seem (to me) to imply a passive monitoring attack. If you get the cooperation of an ISP, that is no longer a passive attack.

Again, this is passive in the sense that it does not require modification of the traffic stream, and as such can be done without any information about the surveillance being observable an the endpoints.

> Page 12:
> - [These attacks all rely on a collaborator providing the attacker with some information, either keys or data.  These attacks have not traditionally been considered in security analyses of protocols, since they happen outside of the protocol.] -> I am not sure if you mean those attacks aren’t traditionally considered in the IETF community or the community at large.

Yep... I'm aware of this. Here we mean "in the IETF community", or more specifically "in the Security Considerations sections for most protocols". We should say so explicitly. Here the threat model commonly addresses a non-participant entities either on or off the path, as opposed to with respect to untrusted endpoints. Case in point: there is no technical protocol mechanism in TLS to keep a TLS endpoint from sharing session keys with whatever entity it wants.

> A secondary point: while the attacks mentioned on page 12 concern a mechanism, what matters from a security/privacy analysis point of view is the state of the matter upon the exposure of the keys/data/etc. (or parts of them), and how that can be used to launch an attack on the security of a system/protocol or the privacy of a user.

This is kind of the point of this section, and to some extent, this whole document. Pre-Snowden "common knowledge" outside the security area about how to analyze a protocol didn't consider these things, and now they must.

Again, many thanks, and best regards,

Brian