Re: what is a threat analysis?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





It seems a bit unlikely all of dozen or so relevant people are simultaneously on vacation, but perhaps that's indeed the case. If so, that's fine, but

And therein lies much of my confusion.

This thread began as a complaint against a particular requirement being imposed on a particular pre-working group effort. It has mostly continued to focus on that. There are only two ADs for the Area under discussion. As far as I know, only one has asserted the requirement for a threats analysis and he had done it with respect to a single working-group-to-be. That one AD is on vacation.

In my view, that one AD is very much trying to be helpful, even as he erected this barrier.

(Given the diversity of goals and views on the mass and now the dkim mailing lists, his requirement strikes as both timely and useful, for getting group consensus about focus, and I am inclined to believe that we really *do* need to establish that before chartering rather than seek it after.)

All other discussion about threat analysis concerns trends, preferences, needs, eventual requirements and the like. Hence, they are abstract. That does not at all make them irrelevant or unproductive to pursue, but it strikes me that it *does* mean the impact of the discussion is, at best, somewhere in the future. While that certainly means we need to press the security community for clear and pragmatic guidance, I do not see how it justifies complaining about the need/requirement.


I am hard-pressed to believe anyone will argue against the utility of a guidance document.

And indeed, nobody is making such an argument. Can we finally put this strawman to bed,

Right. I was merely trying to establish a base of agreement, not to claim you had been claiming otherwise. (Again, I'm just a tad sensitized to diversity of views, given the range of directions the DKIM list discussion is going, so I want to be careful not to make implicit assumptions.)


We have relied on the communication of guidance and
criteria through other means.  So I think the real question is whether
reasonable, clear, stable criteria are being communicated?

That's the question in a nutshell. And it is my belief that this is not
happening.

I posted a note citing the guidance details we've been given by our AD. I (we) would have loved more notice of the requirement as well as a written, pedagogical cookbook for satisfying it.

As for the timing of getting the requirement (only a few days before the BOF) I'll take that sort of "sudden" imposition at the *beginning* of a group process, over the more-typical late-stage surprise any day of the week.

Since I'm the one that has had the most interaction with our AD on this requirement for DKIM, I can only say that I view the sequence as reasonable, although obviously needing more work. Yes, it's unfortunate that some of us who heard him impart the requirement misunderstood it. But some of us did not.


Since the "threat analysis" requirement is newly-imposed on the rest of us, one can expect a period of time where the communication is iterative and maybe even looks like a negotiation.
I would not characterize it as such. An iterative clarifying process might
serve to crystallize management thinking as to what's needed, but ideally it should not result in the sorts of changes implied by a give-and-take
negotiation process.

If I thought that a) our AD and the security community were entirely clear about the requirement as it applies to an Internet standards process, and b) those of us who will be doing the working group work were automatically able to perform whatever clarified requirement they settle on, then I would agree that it is a clarification process, rather than a negotiation. I think, however, that things are rather more fluid. Hence "negotiation".

That said, we probably don't have to agree on the terminology and I'm only commenting because you and I seem to have such different perspectives on this and my comment might help, ummmm, clarify the difference.


Numerious recent events compell me not to share in your enthusiasm. As John
Klensin has remarked in a separate thread, it now seems that the stock response to any suggestion or criticism whatsoever is either some sort of strawman or reductio ad absurdum argument.

Somehow, I suspect this is where the real tension lies in this exchange. And I've probably made enough public comments to make clear that this larger, IETF management problem is one that you and I (and John and a host of others) agree on.

And it is certainly true that the threat analysis pre-requisite for dkim chartering could become an exemplar of this problem.

My point, however, is that my own experience is that... so far... it isn't even close. It feels nothing at all to me like an example of the historical (and very serious) problem.


      So the question about the threat analysis requirement is whether an
effort that has this requirement imposed on it gets the help it needs to
satisfy it?

I confess to a bit of amusement in seeing that you yourself have characterized this in terms of "imposed requirements". If I were Brian no doubt i could read volumes into this choice of words.

You probably won't be surprised to hear that I chose the word carefully. The only surprise might be that I'm not complaining about it.

The reasons are pretty simple: We are asking an AD to support the activity. It is entirely the AD's choice whether to do this. So the question is what he needs to be satisfied. He's imposed this requirement as a basis for gaining his support. This is entirely reasonable, within current IETF rules. I happen to think that it is also reasonable given the highly problematic histories (yes, plural) of the domains (yes, plural) dkim is working in and the obviously problematic pattern on its mailing list.

It would be a very different matter, indeed, if there were an IETF-wide (or even a Security Area-wide) formal rule about all this. At that point, yes, we damn well better get clear, reasonable documentation of how to satisfy it.


As it happens I don't think of this as an imposed requirement, although the way this has been handled may make it seem that way. Rather, I see the need for
careful analysis as an unavoidable consequence of the specific space we're
working in. The security folks are merely pointing this out.

The "imposition" is that it is pre-chartering.


 But guidance really has to
come from the people tasked with managing and approving this effort.

DKIM is the only, immediate exemplar I know about. I believe DKIM is in a process that is getting the guidance it needs from the AD who is imposing the requirement at this stage. He needs to keep giving it. I've no doubt he will.

Let me pound this into the ground a bit more: Like many of us, I have quite a bit of experience with ADs who are unreasonable and I have a fair amount of experience pushing back on them. What is happening with DKIM, in my view, is absolutely NOTHING like those other experiences.


As I have stated previously, writing and reviewing these sorts of
specifications is really hard work, work I see no point in starting in the
absence of a clear statement of what's actually needed.

I've noted the comments folks have made, about the effort needed to do a thorough threat analysis. However it is not at all clear to me that we are be required to produce anything that extensive.

At the moment, we do not even have agreement about the basic threats to which we are responding. I posted some draft text that attempts to do that. It is in a form similar to one I did informally for Russ some months ago, for a different specification. He said it was in the right direction. So I am hopeful that my current text, or some other text of a similar style, will also be a useful base.

The effort needed to produce that text was not trivial, but it also wasn't large.

--

  d/

 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]