The reason I brought this to this list is because there's
no clarity about what is meant by a "threat analysis", though
it seems to be cropping up more and more in the IETF process
(look ma! no hoops!). If it's going to be part of our process,
then I think its incumbent on those who want to impose the
process to be clear about what they're asking for, and for
that process to not be an idiosyncratic. The waste of time
here is not the process per se, but the work on drafts,
etc, that are not what the person making the demand is asking
for. Do you have an objection to clarity in process?
I personally consider threat analysis an integral part of protocol
design. A well written security consideration should read very much as a
threat analysis: what are the system's assets that need protection; what
are the possible interfaces through which attacks can be conducted;
enumerate the likely attacks through those interfaces; ensure that all
these attacks are properly mitigated. Doing that at design time is much
easier than trying to retrofit security when attacks are found in the
wild.
As Eric Fleischman pointed out, doing good security analyses requires
training. In particular, the enumeration of possible attacks looks very
much like a brainstorming session, and relies on the expertise of
working group members. However, members of an engineering organization
like the IETF ought to be eager to acquire such training. I mean, do you
really want to design insecure protocols?
For those interested in self training, I recommend the book "Writing
Secure Code, Second Edition" by Michael Howard and David LeBlanc
(http://www.microsoft.com/mspress/books/5957.asp).
-- Christian Huitema
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf