draft-farrell-perpass-attack architecture issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Thanks,
S.

[1] https://www.ietf.org/mail-archive/web/ietf/current/msg84996.html
[2] https://tools.ietf.org/html/draft-barnes-pervasive-problem





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]