Hi Stewart, On 12/17/2013 11:06 AM, Stewart Bryant wrote: > On 16/12/2013 20:39, Stephen Farrell wrote: >> Replying to a bunch of things at once: >> >> On 12/16/2013 06:48 PM, Andrew Sullivan wrote: >>> Adding the sentence, "In addition, to qualify as pervasive monitoring, >>> the activity should be either unknown to or unwelcome by the target of >>> the monitor," would make the difference explicit. >> I disagree. Even if X% of people agreed or approved or authorized >> the attack, it would still be an attack. While one might have an >> argument if X approximated 100, that's just not the case. > An example of 100% would be an employer doing anti-malware > filtering, monitoring for spyware or trapping the export of intellectual > property, where consent for traffic monitoring is a condition of > employment. > >> And user >> consent is a huge rathole that's not meaningful for most protocol >> design activities, so I also disagree with including variants of >> Andrew's suggestion, as well as disagreeing with the statement. > The issue is where a protocol needs to be designed to operate > in two modes - PM=OK and PM=NotOK. I think what we want is to setup the definition so that we never need PM=OK. And I think the current definition does that - in your corporate example I don't think that is a case of pervasive monitoring, since it wouldn't really fit the "very widespread" part of the definition. So I think its non-pervasive monitoring. To be clear: I'm not saying that I like or dislike such non-pervasive monitoring, but I don't think its pervasive monitoring as defined here. Going back to the hums in Vancouver as a useful reference, there was not an overwhelming hum for considering such non-pervasive monitoring as an attack. I can't recall the exact question now though sorry - I think it was about middleboxes but the implication I think is that non-pervasive monitoring is at least sometimes ok, and the suggested text sent to the list earlier describes that (better than -02 does I think). > Unless antiPM is > conditional the protocol would not be of use in an environment > requiring PM. If we get the definition right (and I think we have it close enough) then there should be no real cases where we have an environment "requiring PM" (for technical reasons) but rather there will be cases of environments that require non-pervasive monitoring, e.g. for n/w management or similar technical reasons. (I do accept that inbound malware scanning is a real requirement, even though I mostly like us all encrypting things:-) I think protocol designers will have to figure out the various cases arising with various antiPM mechanisms, and it'll depend. Say if antiPM feature was to not send the full QNAME in a DNS query from a recursive resolver in your DMZ, then that should not be a problem for your corporate whatnot. (Assuming that particular antiPM mechanism gets worked out fully etc.) The same should be true for any antiPM mechanism that takes the "just don't send it" approach maybe. If the antiPM feature is to e2e encrypt application layer payload with endpoint authentication then yes the corporate whatnot will be problematic for that protocol, or vice-versa depending on your perspective, whenever that e2e crypto is used. So protocol designers in that case will need to deal with the tension that is called out in the draft. S. PS: Please note that this BCP does not call for crypto being mandatory to use. Should the IETF want to go there, that would be a different debate, best not confused with this one. > > - Stewart > > > >