Re: what is a threat analysis?

> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf