SB> My view is that we need to get a much better handle on what SB> that balance is before we publish this BCP. To do otherwise SB> is going to stall IETF work and result in an inconsistency SB> as IDs make the "case law". +1 Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: ietf [ietf-bounces@xxxxxxxx] On Behalf Of Stewart Bryant [stbryant@xxxxxxxxx] Sent: 11 December 2013 12:27 To: draft-farrell-perpass-attack@xxxxxxxxxxxxxx; ietf@xxxxxxxx Cc: iesg@xxxxxxxx Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice Pervasive Monitoring is an Attack draft-farrell-perpass-attack-02.txt This BCP simply records the consensus to design protocols so as to mitigate the attack, where possible. SB> "where possible" has huge implications, since it does not SB> define where on the scale unnoticeable cheap to leading SB> in technology and cost the boundary lies. SB> I hope that you mean "where economically feasible SB> within the context of the application" More limited-scope monitoring to assist with network management that is required in order to operate the network or an application is not considered pervasive monitoring. SB> This discussion on the tension between monitoring for good and bad SB> reasons focuses on network management in the technical sense. SB> However there are many legitimate reasons for traffic analysis SB> and traffic content monitoring that go beyond the basics of SB> network management. SB> SB> Our technologies are used in many environments and we need SB> to ensure that they are fit for off of those environments. SB> For example there are many reasons why a business may need SB> or even be required to monitor, filter and record the content and SB> the metadata of the traffic they flows through its networks. SB> SB> There is also the issue of the tension between privacy and SB> the big data models that are the economic fuel that enables SB> many cloud and Internet services to be affordable to many SB> Internet users. SB> SB> I thus think that we need to be very careful with setting SB> the scope of permitted monitoring enabled by protocols SB> in such a restricted way. SB> I think that we need to say something of the form: SB> SB> Note that limited-scope monitoring required in order to assist SB> with network management or that is required in order to operate the SB> network or an application are not considered pervasive monitoring. SB> Equally monitoring that the user consents to in order that the SB> operator may operate the network or provide a service economically SB> or monitoring in compliance with local regulations should not be SB> considered an attack. SB> There is though a clear potential for such limited monitoring mechanisms to be abused as part of pervasive monitoring, so this tension needs careful consideration in protocol design. Making networks unmanageable in order to mitigate pervasive monitoring would not be an acceptable outcome. SB> Again I am concerned that network management (unless you have SB> a far broader view of what NM is than I) is simply too narrow SB> a scope for permitting monitoring. But equally, ignoring pervasive monitoring in designing network management mechanisms would go against the consensus documented in this BCP. An appropriate balance will likely emerge over time as real instances of this tension are considered. SB> My view is that we need to get a much better handle on what SB> that balance is before we publish this BCP. To do otherwise SB> is going to stall IETF work and result in an inconsistency SB> as IDs make the "case law". SB> SB> Some text of the following form would also be of use in the draft: SB> SB> An protocol defined or modified to mitigate monitoring SB> MUST take into account the deployment needs and economic SB> realities of the broad spectrum of operators, who will SB> deploy the protocol both now and into the foreseeable future. It is also important to note that the term "mitigation" is a technical term that does not necessarily imply an ability to completely prevent or thwart an attack. As in common English usage, this term is used here in the sense of "make less severe, serious, or painful." [OED] In this case, designing IETF protocols to mitigate pervasive monitoring will almost certainly not completely prevent such from happening, but can significantly increase the cost of such monitoring or force what was covert monitoring to be more overt or more likely to be detected (possibly later) via other means. SB> I think that the above is stated backwards. Surely we should state up SB> front that the goal, as with most security, is to increase the SB> cost of monitoring to a find a more acceptable point on the SB> cost-return curve in the light of current technology and ideally SB> to be able to maintain this as technical capabilities change over time. - Stewart