Hi Stewart, Thanks for the comments. I do think the main point you raise is one that warrants discussion and seems similar to Eliot's but clearer, at least to me, (I still don't get Eliot's real issue;-) On 12/11/2013 12:27 PM, Stewart Bryant wrote: > 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. That's maybe fair. OTOH, "where possible" may be the most precise we can get without either neutering the BCP or dragging it into endless ratholes. (But see below.) > SB> I hope that you mean "where economically feasible > SB> within the context of the application" I don't think it means exactly that. I think "where possible" in this context means "considering the other constraints faced in the design of IETF protocols." If it helped to add that without enumerating those other constraints then I think that'd maybe be ok. > 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. That's a fair comment, but I've not seen any suggested alternative that'd not neuter the meaning of the BCP so far, including yours below. > 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. Thanks for the concrete suggestion, but I have a number of problems with that text: - Required in order to operate the network is very vague and could be used to justify almost anything at all. What would *not* be justifiable with that text? (See my response to Alissa on that just now, which makes the same point.) - User consent is a rathole that I think we have to avoid. Would an EULA then mean that users have consented to pervasive monitoring? If you read most of those then they generally have the user give up everything. And how would a protocol designer ever know if a user had consented to something or not? I don't think we can include any mention of user consent in this BCP. - I don't think we should call out economics in a BCP like this. All IETF work is constrained by a number of practical factors, including economics but also performance, fairness, fate-sharing and loads of other things. We shouldn't be calling all or any of those out here. - Local regulations again adds that huge ambiguity when considering RFC 2804. I really don't think that this BCP should be used to try to re-do the raven discussion or cause WGs to have to re-do that over and over. Adding that phrase would have that detrimental effect. So again, I do agree that the network management bit is not perfect, but every alternative so far seems far worse that the -02 version to me at least. (And others have expressed that concern as well.) > 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. I think any change there would be easy enough if we could figure out a non-neutering change to the text earlier in that paragraph. > 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". Mine fwiw is that we should document the consensus that was overwhelming in the room in YVR and then work out the details based on real protocol design issues as those arise. I don't believe that we can or should try to build a theoretical castle in the sky before documenting the most significant bit of the consensus. To give another reason for that - today, we don't have (IMO) any practical scheme for e2e email security that'd usefully mitigate pervasive monitoring when a service provider either colludes, is coerced or hacked. In that particular case, I don't have much hope we'll solve it soon, but if someone did come up with a scheme that made a significant difference then this BCP should be usable for them to argue that the IETF should be doing work on that when or if we're working on mail standards. So its not actually possible for this BCP to fully describe all the details since we don't have practical solutions in many of the e2e cases today. > 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. Again I don't think calling out "economic realities" like that is correct. We shouldn't design our protocols for just the current business models that people have since those change over time. Not that long ago, many people could have argued that no IETF work matched the economic realities and even today, there are many places where the economic realities are sufficiently different that such constraints are not appropriate to include in a BCP like this. Note - I'm not saying that WGs should ignore economic issues, but that we should not call them out here. > 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. I don't think about it solely in terms of monetary cost, and nor I think will a lot of users. Service providers and implementers do of course, but that cost-return isn't the only consideration at least not until you take into account reputation costs and opportunity costs and so on, all of which are pretty vague. And that's not even mentioning whatever it is that users think about giving up privacy. So when considering a threat the ideal (which is generally not possible) is to completely mitigate that threat, and all we're saying here is to expect even more imperfection than usual;-) I think we do need to say that, otherwise we may create the false impression that we're claim to solve the problem. Cheers, S. > > - Stewart