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