ietf
[Top] [All Lists]

Re: what is a threat analysis?

2005-08-11 15:08:36
Your view of requirements for IETF process do not match mine and your
assessment of the current situation with the DKIM effort does not match mine.

They match mine pretty well, however.

In fact I do not know what specific behaviors, and by whom, you are
complaining about.

Actually, I think Michael has been quite specific in his complaint, and I'm
behind him 100%.

> My issue is that if people are going
> to invoke process, they should be prepared to define what
> the process is. And not just hand waving; concrete pointers
> to documents that have been through the rough consensus
> mechanism so that all parties can shoot for a common
> goal.

The requirement for a threat analysis, prior to chartering a DKIM working
group, was stated by our cognizant area director.

Nobody is saying that having such an analysis is a bad idea.

He provided concrete,
written guidance, in the form of the 3-point questionnaire that I've cited. It
would be delightful to have a tutorial, but what he gave us is a long way from
hand-waving.

The three points that were given are simply another way of describing what goes
into a generic threat analysis. So I guess it is fair to say they aren't
handwaving.

However, as far as I can tell they offer no guidance whatsoever about the scope
and direction of the analysis, which is vital lest we work on the wrong thing.

As I said before, perhaps I'm just being dense and not seeing how this tells us
what to do. But simply reiteraling that these points have been provided isn't
telling what I'm missing.

My own comment at the plenary was a very long way from a complaint about the
handling of the DKIM effort. It was, rather, a request for more assistance, in
the form of a) work by the security community to develop better,
community-wide consistency about the term, and b) more tutorial guidance for
completing this thing being called a threat analysis.

Dave, there are at least five RFCs (4016, 3837, 3833, 3756, 3694) that analyze
threats in onw way or another. There are also plenty of other examples in the
security literature, so examples, at least, are fairly abundant.

However, if you look at these you'll find that some of them look at threats to
entire services, others look at attacks on specific protocols, and still others
try and model various sorts of attacks. There are lots of ways this particular
tool can be used.

While it would be really nice to have a "guide to performing threat analysis"
and I think the increased calls for such analyses (which did not start with
MASS/DKIM) mean the production of such a guide should be a work item for the
security area, I don't think the lack of such a guide is the real issue here.

It would be great to have rough consensus about all things at all time, but if
you think about that for more than a millisecond you will see that it is a
good way to ensure never doing anything new, and more likely never doing 
anything.

Again, there is nothing new about calling for threat analysis as part of the
IETF process. What is new, or different, in my experience at least, is having a
call for such an analysis with no guidance as to scoping or direction.

ps. On the DKIM mailing list, I have twice posted requests for discussion
about some draft text describing the threats to which DKIM responds.  As
nearly as I can tell, your own postings, there, have been about an aspect of
the DKIM specification, rather than about the threat analysis.  We are,
finally, starting to get some focus on the topic, so I encourage you to help
us try to develop rough consensus on our own threat analysis effort.

I will again repeat that I have zero interesting in discussing the analysis you
have started writing until I have some assurance it is headed in the right
direction. I will also add that my best guess is that what you have is fairly
wide of the mark. More specifically, what you have is focused fairly
narrowly on spam and forgery, whereas my guess as to what is being
asked for is a much more general analysis of email threats.

                                Ned

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf