Hi Tony, (Subject lines are cheap and helpful, let's try use 'em a bit better please.)
On 10/14/2013 04:35 PM, Tony Rutkowski wrote: > Steve, > > Brian's draft defines "pervasive surveillance" as >> the practice of >> surveillance at widespread observation points, without any >> modification of network traffic, and without any particular >> surveillance target in mind. > There are a couple of obvious deficiencies here.. > > As a starter, the definition is self-contradictory. > The first sentence in the introduction uses RFC6973's > definition of surveillance with is aimed at an individual > and concatenates it with "pervasive" to come up with > something that says there "is no particular surveillance > target in mind." Which is it? You cannot logically > concatenate the two notions together. I don't see the contradiction. I'm sure wordsmithing will be needed of course, and we'll want a better definition of pervasive monitoring for sure. (See earlier comments on the draft in the list archive.) > You s/You/the draft/ I guess. > also don't deal with timeframes. Most Big Data > implementations for all kinds of purposes, acquire > observations and sort out the metadata. That's how > particular particular targets (e.g., purveyors of cheap > nuclear devices) are found, and it's mandated by law > under the E.U. Data Retention Directive. Timeframes are an interesting aspect to consider, I agree. > Additionally, all this is context dependent as there all > kinds of bases for exactly this kind of activity that are > operational, commercial, and legal. It would also be > interesting to see a definition of "network." Radio > networks have been subject to constant monitoring > for many decades. Fast forwarding to SDNs and Cloud > Computing services, renders most of these this efforts > irrelevant. Huh? I don't get what you mean. > Then after proffering a definition, the religious statement > appears: "we presume a priori that communications systems > should aim to provide appropriate privacy guarantees to > their users, and that such pervasive surveillance is therefore > a bad thing." "Presume a priori?" Yep. For this draft, such an a-priori assumption is ok I think - the point is so that when its done (and its a -00) it'll be useful for protocol designers who need to consider this threat model. So its not at all "religious" here (and incidentally, I figure such terms are purely pejorative, and not generally helpful). > There are innumerable > contexts where privacy - which is itself a socio-political- > legal abstraction - is not relevant or applicable. Can you enumerate some real cases where someone might be designing an Internet protocol and where privacy is irrelevant or not applicable? That kind of scoping could be useful, if such cases exist. > Similarly, the "perfect passive adversary" definition is a > self-contradiction. If the observer is taking no action, > there is no threat by definition. > >> We explicitly assume the PPA does not have the ability to compromise >> trusted systems at either the initiator or a recipient of a >> communication. > Give me a break. Ok, take a break:-) > Here again, an assertion is made that > is simply not credible. Essentially all systems are > capable of compromise - either technically, lawfully, > or through insider threats (which is generally regarded > as the greatest threat). As it happens I also commented on the definitions, and I agree they do need work - that's what'll happen as the draft progresses. > If you want to analyze any of this within the context of > substantive ongoing work, you should consider applying > the STIX threat analysis/exchange model. Do you mean this? [1] S. [1] http://stix.mitre.org/ > > This kind of work tends to turn the IETF into a script > writing exercise for the third season of VEEP. > > --tony > > On 10/14/2013 9:43 AM, Stephen Farrell wrote: >> Personally, I entirely disagree. It is true that we >> don't have a worked out threat model for this yet, >> but Brian's draft is a start on which I hope we'll >> build so that protocol designers, implementers and >> those deploying networks and services will have a >> useful threat model to use when doing their work. > > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
