Hiya, On 12/31/2013 07:02 PM, Rene Struik wrote: > Dear colleagues: > > While I do agree with some of the underlying sentiments of the draft, I > am not that happy with the somewhat sloppy exposition of the draft, in > particular to what problem one really wishes to address (see #1, #2 > below). Moreover, I feel that the implicit suggestion of the draft that > one should take an almost binary approach to addressing passive attacks > may be detrimental at achieving a solid security architectural design > (it should be a proper balancing, rather than 0-1 thinking w.r.t. one of > many security architectural considerations). Sorry - what text suggests a binary approach? Please do give quotes, as that is not the intent, and nor is it expressed. In fact the draft says: "The IETF will work to mitigate the technical parts of the pervasive monitoring threat, just as we do for other protocol vulnerabilities." I really don't see how that can be mis-interpreted as a "binary" approach. Can you explain? > > In my mind, the draft needs to be more carefully written, so as to make > intent and grey scales of proposed design metrics clearer. More details > below. > > Some technical comments: > > 1) In Section 1, 3rd para, the term "attack" (in the context of > pervasive monitoring) is too broadly defined: pervasive monitoring is > (an extreme form of) monitoring and, thereby, an attack form that has > been dubbed (decades ago) in the cryptographic literature as an attack > by a *passive* adversary. No. We are not defining pervasive monitoring as being purely passive, since it is not. And nor is it an active attack entirely. So its correct that the definition is that broad and differs from either passive or active attacks. I think a perhaps lot of your other comments hang on this misunderstanding. But I'll comments on bits of those below. But what you call a misnomer is deliberate, and is needed IMO. I'd welcome a better definition if we can find one. > (The fact that this may happen on a massive > scale does not change its nature.) In the draft, though, one seems to > lump this together with other attack forms, where a passive adversary > may exploit insights gathered from passive attacks to subsequently > facilitate an active attack (witness the use of "to enforce the > opponent's will on the attacked party" in 3rd para, 3rd line or "that > subverts the intent of a communicator without the agreement of the > parties to the communication" in 3rd para, 6th line). The latter is an > *active* attack, which is not part of pervasive monitoring itself (but > only may take advantage of this). The active aspect is also a part of pervasive monitoring as defined here, and needs to be considered as such. For example, if an RSA private key is exfiltrated via an active attack in order to later decrypt non-PFS ciphertext. (As in the Belgacom case perhaps.) That is part of the pervasive monitoring attack, but is not well described as either passive nor active. > With passive attacks, in most cases > (e.g., when using wireless communications) the presence or absence of an > passive adversary cannot be distinguished. I would strongly suggest > using proper notions and avoiding confusing and ill-defined terms (for > definitions, see, e.g., Definition 12.15 of the Handbook of Applied > Cryptography (CRC Press, 1995)). Shouldn't one simply change the title > of Section 1 to the (somewhat obvious) statement "Pervasive monitoring > is Indistinguishable from a Passive Attack" or "Pervasive Monitoring > Cannot Be Distinguished From Non-Monitoring, So One Should Prepare For > the Worst"? No. It would be wrong to only consider pervasive monitoring as a passive attack as that is not the case. I think our conceptions of passive and active have in fact held us back to an extent in that they may have made us less likely to recognise the potential for the pervasive monitoring attack which mixes both approaches and at scale. > 2) In Section 1, 4th para, if the intent of the draft is to also raise > awareness of active (pervasive) attacks, it should say so clearly and > not suggest, as it seems to do right now, that this is due to "pervasive > monitoring" (since, as already said, this is a misnomer). Here, again, > though, this is nothing new by itself: security services need to be in > place where the interests of communicating parties, including the > communicating networks used by these parties (and lurking adversaries > therein) are not aligned. I would suggest emphasizing, far more than > currently done, the role pervasive monitoring could play in paving the > way towards providing useful insight to make a subsequent (or > interactive) active attack more successful, since that seems to be one > of the underlying currents of the draft. No, the main purpose of that paragraph is to empahasise that the IETF don't need to take a position on the morality or otherwise of e.g. specific NSA or GCHQ motivations. We can and do say that their actions are an attack, but we do not say that their motivations are good, bad or indifferent. That is necessary so that when someone misinterprets the draft as saying that "the IETF says that NSA are bad" they can be corrected by pointing at this text. The text in this draft *will* be deliberately misinterpreted by some for their own ends so this really is needed. > 3) In Section 1, 1st para, it is stated that " [...] that this was an > attack that should be mitigated where possible via the design of > protocols that make pervasive monitoring significantly more expensive or > infeasible". While I wholeheartedly agree that protocol design should > include privacy-relevant objectives (such as hiding header info and > meta-data), to me it seems this should always have been in the security "should always have been" is correct from a security and privacy perspective. But it is clearly the case that such consideration has not been a typical part of current or past practice. Hence the need for this BCP. > services objective list with security and communication protocol design > and it is somewhat surprising to see that this apparently is something > new (or, do I read this in the wrong way?). Isn't the main change > between the pre-Snowden and post-Snowden era that one is now aware that > would should attach more weight to security objectives one may very well > have unrightfully ignored in the past??? I am really concerned that this > becomes now a single quest at the detriment of other security objectives > one may wish to cater to. Sigh. "Single quest" is a very weird mis-reading of the draft. See the text quoted above. I honestly don't get how you end up thinking that. > After all, with security and communication > protocol design, one should balance different objectives according to > deployment scenario at hand and there are many, many considerations that > could play a role. To this point, I already expressed concern in an > email of September 6th (see > http://www.ietf.org/mail-archive/web/perpass/current/msg00099.html) That message was not in relation to this draft. I don't know what you mean in quoting it sorry. Can you clarify how it relates to this draft? > that, e.g., trying to avoid traffic analysis by making all frames the > same size would be disastrous for applications in a highly constrained > setting ("internet of things", "smart objects", and the-like); I also > epressed some other concerns with respect to binary thinking here (see > the link). I would therefore suggest to express the desire of IETF-88 > somewhat more intelligently and stipulate, e.g., that protocol should > properly consider security objectives and weigh these and allow security > policy settings to be picked so as to, indeed, enable more privacy-aware > deployments. This is mostly a security policy issue, though, and should > less so be a fixed setting of a security protocol itself. One could dub > this "security policy agility" vs. "crypto agility" if one wishes.... > (Note: TLS is an example of a somewhat unfortunate design here, where > one has no security policy agility to hide lots of parms in the protocol > flows at all). The main point of post-Snowded would then be that the > "security policy agility" should include the policy to enable privacy > protection to one's heart content. I have to say that the above seems to me pretty unclear in comparison to the current text. (But I would think that of course:-) > > 4) Section 2, 2nd and 3rd para, seems to be a somewhat hidden admission "Hidden" is not what I think. I think we have failed in some respects, and generally not done so well in respect of privacy. > that, perhaps, IETF itself may in the past not have done as good a job > as it could have in considering and weighing all security objectives. > After all, notions of passive and active attacks have been around for > decades, but apparently some of this has been not taken too seriously > for a while, or would have been considered "too expensive" to > implementers or vested interests? It can hardly be considered news that, > e.g., if one does not use adequately secured packets, then visible parts > may be eavesdropped upon, etc. Right now, it reads as if one is > indignified even in case one sends entirely unsecured packets and that > this, surprise, surprise, may be vulnerable to attack. To some network > people, it may be considered news if protocol messages do not behave as > specified. To security people, this should be second nature: after all, > all networks and network components should be considered as gigantic > security engines, without constraint on actors on the communication > channel. Sorry, I don't get what your comment is getting at. > > 5) Section 2, 5th para, seems to be an admission that protocol design > should intelligently weigh design objectives (e.g., so as not to rule > out monitoring for network monitoring purposes). So, if this means one > wishes to cater for "security policy agility" as I alluded to above, so > much the better. I wouldn't call it an "admission". Again though, I'm not clear if you're asking for some change or not. Cheers, S. > > Best regards, Rene > > On 12/3/2013 12:48 PM, The IESG wrote: >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Pervasive Monitoring is an Attack' >> <draft-farrell-perpass-attack-02.txt> as Best Current Practice >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@xxxxxxxx mailing lists by 2013-12-31. Exceptionally, comments may be >> sent to iesg@xxxxxxxx instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The IETF has consensus that pervasive monitoring is a technical >> attack that should be mitigated in the design of IETF protocols, >> where possible. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> > >