> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf