Pervasive Monitoring Is an Attack
Summary: Needs 3 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 04 and is now closed.
Jari Arkko Yes
( Richard Barnes ) Yes
( Ted Lemon ) Yes
( Pete Resnick ) (was No Objection) Yes
Comment (2014-02-06 for -05)
Jari has made a good case that there is rough consensus for BCP.
Martin Stiemerling Yes
( spt ) (was Recuse) Yes
( Gonzalo Camarillo ) No Objection
Benoit Claise (was Discuss) No Objection
Comment (2014-02-11 for -06)
Now, I will try to convince myself that this document is more a statement of principles than an enforcement tool. THE only sentence that goes in this direction is: "An appropriate balance will emerge over time as real instances of this tension are considered." This is pretty light and goes against : The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible. Regardless of what the authors may say now, I have some concerns, as others have expressed during the IETF LC asking for more balance, that this document will be used as an enforcement tool against some future OPS developments. However, nothing really actionable at this point, except if the community would be ready to add: "this document is more a statement of principles than an enforcement tool."
Spencer Dawkins No Objection
Comment (2014-02-06 for -05)
Updated at the bottom ... I'm mostly OK with the text in -05, but in section 2, I'm concerned that the draft is accurately reflecting conflicting goals: - we need to mitigate PM - we need to allow limited-scope monitoring - we can't tell the difference in any technical way, so - I'm not sure we can do both at the same time Do we think we can figure that out? Without resorting to http://www.nancyclaxton.net/uploads/3/4/6/9/3469502/525284.jpg, of course. Update: I'm looking at 3. Process Note In the past, architectural statements of this sort, e.g., [RFC1984] and [RFC2804] have been published as joint products of the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB). However, since those documents were published, the IETF and IAB have separated their publication "streams" as described in [RFC4844] and [RFC5741]. This document was initiated by both the IESG and IAB, but is published as an IETF-stream consensus document, in order to ensure that it properly reflects the consensus of the IETF community as a whole. I honestly remembered this text saying something different than it says. I thought the plan was that the IETF and the IAB agreed, so we would have published the doc jointly, but we now have separate streams, so ... But all I'm seeing is that the IESG and IAB both *initiated* this draft. Is that all the IAB is likely to say? (he asked the IESG and not the IAB, but mumble) I started to edited my comments to ask "what does it mean when the IAB endorses this but the IETF publishes it as Informational?", but obviously I've gotten ahead of that question - sorry.
( Adrian Farrel ) No Objection
Comment (2014-02-01 for -05)
I would really, really, really, prefer this document to go as Informational. I find that it takes a deal of wriggling to make this fit the 2026 description of a BCP (although I will grant that that wriggling can be done successfully). The bulk of the text is set up to provide information about what PM is and how it is considered an attack: only a tiny bit says what we will do about it. That last is the potential BCP bit, but the document really doesn't say enough about what we will do to warrant being a BCP. I am relatively sure that I heard one of the authors say he didn't much care whether it went as Informational. Being Informational ratheer than BCP will address a number of concerns from the community. While I heard many voices saying "make it Informational" I do not recall hearing positive voices for BCP (distinct from people saying you don't need to change it). I don't believe this is a Discussable point, but I think the authors and shepherding AD should thing about this a bit more. --- Each time I read the document I am bothered by the use of "Attack". The problem I have is exactly explained in e third paragraph of the document, but that is too late. The issue is that the term "attack" is being used in a specific context (that of security) in a document that has a wider readership and applicablity. The largest concern I have is evidenced by a number of comments received in reviews, and it is that this specialist usage of a word is not perceived by some readers who then get "upset" by the statement that this is a normal-English-language-meaning attack. The telling point for me is that the Abstract actually sensed this issue and used "technical attack" which is kind of helpful although it is a third term that is not used elsewhere in the document. I took the precaution of talking to a copy editor about how one normally handles this sort of issue, and the answer leads to some simple changes to the text. The general solution is to use "Security Attack" instead of "attack" thereby using a term that fits the paragraph 3 definition and clearly indicates that a specialist maning is being applied. So: - Document title s/Attack/Security Attack/ - Running header s/Attack/Security Attack/ - Abstract s/technical attack/Security Attack/ - Section 1 para 2 s/attack/Security Attack/ twice - and so on throughout the document I fully expect to hear back that this is a fiddling little change that is not worth the effort. I think it is worth the effort and makes a big difference and will happily make the edits. Again, this is not something that can be Discussable, but given that the readership of this document will be wide, it behoves us to get this tone correct. --- Section 1 para 2 PM is distinguished by being indiscriminate and very large-scale, rather than by introducing new types of technical compromise. Could clarification. suggest it belongs in para 1 not inbetween two sentences about the IETF's views. --- Section 1 para 4 The motivation for PM is not relevant for this document, but can range from non-targeted nation-state surveillance, to legal but privacy- unfriendly purposes by commercial enterprises, to illegal actions by criminals. The motivation is not relevant in this document, but we are going to talk about it anyway :-) Great to say it is not relevant. Then stop! But I suspect you wanted to say "We are not specifically targeting governments in this document" in which case, perhaps it *is* relevant for this document. Perhaps what you needed is... The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation. Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols. --- The text in the main body carefully says It means that, if asked, there needs to be a good answer to the question "is pervasive monitoring relevant to this work and if so how has it been considered?" Yet other text says should be mitigated in the design of IETF protocols, where possible. The correction is probably s/where possible/where appropriate and possible/ --- Section 2 para 1 Protocols that mitigate PM will not prevent the attack, but can significantly change the threat. Don't agree that all mitigation is only partial. Thus s/will not/might not completely/ --- Section 2 para 2 But those generally do not consider PM Previous sentence has "standards", "mechanisms", and "guidelines". To which does "those" apply? Suggest "those <insert noun> generally" Is "generally" used because we haven't checked all the documents? --- Section 2 doesn't half ramble on. I lack the energy to suggest a reduced version at the moment, but surely it could have been said in a quarter of the number of words. --- Section 3 says: This document was initiated by both the IESG and IAB Perhaps I slept through that meeting. ==== Nits Section 1 para 1 "...can also be used..." I think that "also" is incorrect and should be struck. The previous sentence did not specify any mechanisms. --- Section 2 para 2 confidentiality of protocol meta-data, countering traffic analysis nor data minimisation. [RFC6973] In all cases, there will remain some privacy-relevant information that is inevitably disclosed by The positioning of the citation seems broken. Should come before period?
Brian Haberman (was Discuss) No Objection
Comment (2014-02-06 for -05)
Thanks for an *interesting* DISCUSSion.
Joel Jaeggli No Objection
Comment (2014-01-23 for -05)
Some monitoring can even be part of the mitigation for PM, for example Certificate Transparency [RFC6962] involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. There is though a clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. In fact there are a number of activities that might fall under the rubrick of pervasive monitoring or in same cases pervasive counter-surveillance (certificate pinning comes to mind for the later) that seem necessary in order to detect more active forms of subversion. This tension with respect to exposure to monitoring also touches on the question of consent, the receiver of unsolicited requests may necessarily have rather different concerns than the sender and that may well result in inputs to protocol design/implementation/usage inconsistent with our concerns.
Barry Leiba No Objection
Comment (2014-01-21 for -05)
Recognising that we could quibble about wording until the document is entirely overtaken by events (such as the death of the known universe), I'll throw in a couple of comments, which you're free to opt out of with no reply needed. The term "attack" is used here in a technical sense that differs somewhat from common English usage. In common English usage, I would strike the second sentence ("In common English usage...") entirely, as it only serves to bring the inapplicable sense to the reader's attention. Just go straight from the first sentence right into, "The term is used here...." We also use the term in the singular here, even though PM in reality may require a multi-faceted set of coordinated attacks. I'd say "consist of", rather than "require". Thus we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required are indistinguishable from other attacks. "the actions required" seems odd here. I think it refers to the actions required for defense, but then it says they're indistinguishable from attacks. I think the best fix is something like this: NEW Thus we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the various actors are indistinguishable from each other in this regard. END This can significantly increase the cost of attacking, force what was covert to be overt, or make the attack more likely to be detected, possibly later. Isn't making what was covert overt also making in detectable? This seems repetitious.
( Stewart Bryant ) (was Discuss) Abstain
Comment (2014-02-05 for -05)
Adrian in his comment of 2014-02-01 articulates extremely well points that have been giving me cause for concern since the first version of this text was put forward, and continue to give me concern. To pick the most important points it is my view that the unqualified use of the word "attack" in most places in the text, whilst sensational does a dis-service particularly in its wider operational context. Secondly I am concerned that PM, or techniques similar to PM have a valid law enforcement use, and that to make PM infeasible (section 1 para 2) would not be in the best long term interest of the IETF designed Internet. The text: "While PM is an attack, other forms of monitoring can be beneficial and not part of any attack, e.g. network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content." can be construed to permit the use of PM or similar techniques in law enforcement but it would be better to explicitly note this. I am also concerned that the lack of explicit guidance on what is needed in IETF specifications will cause difficulties with future RFCs resulting in inconsistent application of the advice in published RFCs. I accept however that there is a strong desire by many in the IETF to submit text for publication before the London meeting, and therefore consider that I should abstain from further discussion.