> All the more reason for those in charge to be quite specific about what
> it is they're after, which still hasn't happened. All we get is more fixation
> on the words Mike happened to use in one message rather than responding to his
> issue with the lack of clarity in what's being asked for.
Minor comment about the "still":
It's a very short time after the IETF meeting. And it's August. Area
Directors are allowed to take a vacation, and even have no Internet
connectivity during the time.
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 (a) A
simple statement to that effect would sure have been nice and (b) We should
then refrain from attempting to construct something that's likely to be the
wrong thing in the meantime. (It should be obvious why getting far down a
specific path, only to be told it is the wrong path later, is a bad idea.)
Not-so-minor comment about guidance:
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, or light it on fire, or do whatever it is you do to get rid of
strawmen?
In fact that's why some of us suggested it to EKR during
IETF week and it is why I made my IETF plenary comment. Since EKR has a track
record of producing security-related document for non-security geeks, I'm
hopeful we will get something useful.
But most of the IETF works has been done without benefit of such
guidance documents.
This has also been pointed out repeatedly.
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.
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.
The question, for this particular requirement, is whether
there is a process to converge on clarity and stability for the requirement.
Although it is early days, I am hopeful. (It helps that the construct involved
has substantial history within the security community.)
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.
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.
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.
Noting that, in reality, an IETF effort always has quite a few
requirements imposed on it, my own view is that most early-stage IETF efforts
gets vastly less help than is needed.
I have believed this ever since some years back the chair of a WG-to-be flew
down from the bay area to literally knock on my door here in LA to ask for help
getting his group chartered. (No, I am not making this up.)
The truth of that matter is that we
mostly rely on a self-forming group to figure things out on its own. At most,
we assign a relatively experienced IETFer to help, but I'm not convinced that
that helps as much as we would like.
For DKIM, our AD met with the design team at the beginning of IETF week
and met with me at the end. He tried to give us pragmatic guidance at the
beginning of the week. Some of seem to have understood it and some of us
clearly did not. Also, EKR sent an extended note about threat analysis to the
MASSS mailing list, prior to our BOF, rather than just showing up at the
microphone and lobbing a bomb at us. I see two questions leading from the
fact of our own confusion about the requirement:
1. Is there something useful we can do on our own about this?
2. Are we (going to get) assistance from our AD?
The answer to #1 *can be* yes.
Of course it can. There is always a chance that if I spin around and shoot a
gun at random I'll hit the target. It just seems like we could do better.
As is clear from a number of the threads on
the DKIM list, the group is not all that cohesive or clear about the
functional requirements DKIM is intended to satisfy. An analysis of the
threats that DKIM is intended to respond to can significantly help resolve the
confusion, separate from whether that analysis is exactly what we have been
asked for. That is, getting the group to be clear and cohesive (rough
consensus) about the goals, motivations, concerns, whatever of DKIM is an
inherent good. And, indeed, there is some potentially useful discussion
proceeding.
Maybe. Around half dozen different documents or document fragments have been
put forward as possible candidate threat analyses. I don't know about anyone
else, but I find it next to impossible to keep them all straight. Nor is it
clear to me which one is the best one to use as a basis for further work.
The answer to #2 is simply yes. Russ (and, by the way, Sam) are trying to be
helpful. As someone with lots of practice complaining about pretty much
everything, I could express all sorts of wishes about how things could be
better. However the fact of the matter is that they are looking for ways to
improve the likelihood of success and they are clearly willing to iterate with
us to get there. It is difficult to reasonably ask for more.
I think I have been very clear as to what I'm asking for. And various people,
most notably Steve Kent, have tried to be helpful. But guidance really has to
come from the people tasked with managing and approving this effort.
That said, I hope we keep the pressure on, to get a document that specifies
the threat analysis requirement in a way that is both clear and useful for
working group productivity.
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.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf