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 protected]> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
