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