Re: draft-farrell-perpass-attack architecture issue

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

 



Stephen,
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.

Although I like including a good example, I worry that this example is
too narrow and may send the wrong message. I suggest using the rest of
Sam's text for para 2, but eliding the DNS example. (I say this because
a protocol may make use of the DNS in a way that I would not consider
to be "storing" info there, on behalf of the protocol.)

Steve




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