Re: what is a threat analysis?

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

 



David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx> writes:
>> From: Michael Thomas <thomasm@xxxxxxxxx>
...
>> At the MASS/DKIM BOF we are being required to produce such a thing as a
>> prerequisite to even getting chartered as a working group.
>
>A more pertinent request at that stage might be, "Please clarify the security
>requirements for this protocol."

I believe that the "threat analysis" that the proposal authors created
in the days before the BOF did the above, documenting how DKIM could be
attacked, what it depended on or assumed, etc.

IMHO however, that's quite different from what ended up being the
sticking point at the BOF, which you see as a paraphase of the above:

>IOW, what is the protocol supposed to
>enforce or protect, under the assumption that it will be used in the Internet
>environment with the "fairly well understood threat model" described above?

To me, _that_ question sounds more like "what does this accomplish?",
which belongs in a use cases doc, or maybe flipped around and placed in
a requirements doc.  In the case of DKIM, that can be phrased as "How
does this address items in the threat analysis for SMTP and the Internet
email architecture?"  From the people I've talked to and what happened
at the BOF, it seems that at least some of the requests that came across
as being for "a threat analysis" were intended for this latter meaning.


IMHO, the phrase "threat analysis for <X>" should refer to the analysis
of attacks, dependencies, and assumptions of <X> and _not_ include the
list of threats to other protocols that <X> addresses.  Those aren't
threats to <X>, they're *opportunities* *for* <X>!

But maybe the people who live and breath security analyses find that the
broader meaning is more useful.  If so, *someone* should document that
fact and security people should actively refer to that document when
requesting such analyses for the benefit of those of us who aren't
versed in the jargon.  That may be a good idea even if security people
prefer the narrower meaning, given the incredibly vague definition in
the FYI cited by Bruce Lilly.


Anyway, a miscommunication occured that resulted in time wasted.  Not
the time spent on the DKIM threat analysis, as that'll be needed later,
but rather the time of _many_ people spent at a BOF that was less
productive than it could have been.  The point now isn't to blame anyone
but rather to avoid this communication failure in the future.  How can
we do that?


Philip Guenther
"Just an email guy"

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

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