On 1/13/2014 2:28 PM, Stephen Farrell wrote:
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.
I agree with others that the example probably needs work. Its not
generic enough. If this is a BCP, that specific example can come back
latter in debates as to what level of security/privacy needs to be
considered, i.e. are we worry about storage (private data leaks) or
the insecure transmission methods or both? So IMO, keeping it makes
the argument for informational status stronger.
--
HLS