Hi Stephen, I oppose the change for reasons I state below: On 1/13/14 8:28 PM, Stephen Farrell wrote: > Hi all, > > Sam raised an issue that we didn't handle in the -03 > version. [1] After some offlist mail between us I think > that his issue would be resolved with a change such as > the one below, adding a new paragraph. > > Should text like this be added to the document? FWIW, > I'd be ok with that, or with leaving this out and for > a slightly longer discussion of the topic to be part > of Richard et al's problem statement draft. [2] > > Please say what you think. > > The proposed change in OLD/NEW form is: > > OLD > > Those developing IETF specifications need to be able to describe how > they have considered pervasive monitoring, and, if the attack is > relevant to the work to be published, be able to justify related > design decisions. This does not mean a new "pervasive monitoring > considerations" section is needed in IETF documentation. 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?" > > NEW > > Those developing IETF specifications need to be able to describe how > they have considered pervasive monitoring, and, if the attack is > relevant to the work to be published, be able to justify related > design decisions. This does not mean a new "pervasive monitoring > considerations" section is needed in IETF documentation. 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?" > > In particular, architectural decisions, including which existing > technology is re-used, significantly impact the vulnerability of > a protocol to pervasive monitoring. For example, if a protocol > uses DNS to store information, then a passive attacker can observe > the queries made to the DNS. Those developing IETF specifications > therefore need to consider mitigating pervasive monitoring when > making these architectural decisions and be prepared to justify > their decisions. Getting adequate, early review of architectural > decisions including whether appropriate mitigation of pervasive > monitoring can be made is important. Revisiting these architectural > decisions late in the process is very costly. > While the sentiment isn't bad it's a bit of a truism, and the example isn't good, since in large part the information shared through DNS can often and more accurately (albeit not always) be gleaned through other means (flow state, for instance). Once again I return to what I have said previously: developers of specifications should examine this on a case by case basis (at least for now), weigh whatever tradeoffs they uncover, and move forward from there. Eliot