Re: what is a threat analysis?

[Michael Thomas <mat at cisco.com>]

Brian E Carpenter wrote:
> Ned Freed wrote:
>
> > > Brian E Carpenter wrote:
> > > > Michael, you've had some quite concrete responses which I hope
> > > > have clarified things, but I really want to say that making
> > > > Internet protocols secure isn't a hoop jumping exercise; it's
> > > > more like a survival requirement, and has been for ten years
> > > > at least.
> >
> >
> >
> > > Where did I say that?
> >
> >
> >
> > Of course you didn't, and the implication that you did say that was 
> > nothing but
> > a strawman, a tactic I'm sad to say often seems to crop up in 
> > discussions on
> > the IETF list.
>
>
> Excuse *me* but Mike's note that I was responding to said (in part):
>
> > So, if this is going to be yet another hoop that the IESG and IAB
> > sends working groups through like problem statements, requirements
> > documents and the like, I think it ought to be incumbent on
> > those people demanding such things to actually both agree and
> > document what it is that they are demanding.
>
>
> He explicitly raised the question of hoop jumping, which for me at
> least carries a strong implication of pointlessness. That's what
> I was responding to.

So you've fixated on the word "hoop". Fine. Delete it
and the original question still stands.

> More recently he said:
>
> > Do you seriously think you could write a "threat analysis"
> > given the definition in 2828?
>
>
> which reads
>   "$ threat analysis
>        (I) An analysis of the probability of occurrences and consequences
>        of damaging actions to a system."
>
> As a glossary definition, that seems admirably clear. 

I repeat: could you write a threat analysis based upon the
definition in 2828? That was suggested by somebody as being
adequately defined for my original question.

> For a complex case,
> I'd expect to ask some experts for help in determining the type of
> threats to be considered in particular. And I would study 3552 carefully,
> warts and all. But the bottom line is that this is hard work to get
> right - compare the Security Considerations of RFC 3056 with RFC 3964
> for example.

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?

		Mike

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf