--On Sunday, June 12, 2005 4:08 PM -0400 Keith Moore
<moore@xxxxxxxxxx> wrote:
I think this begs the question of whether currently known
and deployable security technologies are actually
adequate to the task of securing our networks and
networked protocols.
well, yes, it quite explicitly begs to have such questions
discussed, but in their own forum and before Last Call for
functions that use them, rather than after.
Well of course we'd like to understand such questions as early
as possible. But that problem is hardly limited to security
issues.
There's a real conflict here that we keep dancing around -
whose job is it to determine the requirements for a protocol
design?
...
Keith,
One can try to make a general, and unsolvable, issue out of
this. One can also look at a narrower question, and I think it
is that question that has me (and Dave) concerned.
Let's suppose we have a standards track document that says "this
is a technique that can reasonably used in situation X". Maybe,
to create the problem of interest, it is sufficient that it be a
standards track document and not say "doing this in any form is
really stupid but, if you insist on doing it, this is the
agreed-upon way".
Now someone comes along with another protocol or BCP that is
being designed. We claim we believe in reuse of protocols,
rather than adopting a "invent everything anew" approach, so
looking for existing tools and protocols is presumably a
reasonable thing to do. I'd like to think that, if a group
finds a standards-track document, checks the various indices and
determines that it hasn't been superceded or moved off the
standards track, and decides on that basis to go use the thing,
they have done due diligence. If "still on standards track"
isn't sufficient to constitute a "safe to use" recommendation,
then I suggest that the IETF is in rather serious trouble. In
particular, if someone, especially the IESG, shows up during
Last Call and says "use of that thing is evil, please drop it",
that is a symptom of a particularly nasty problem.
There are all sorts of other cases where the problems are lots
different and it appears clear that insufficient attention was
paid to existing standards and norms of protocol design. My
recent appeal about the MMS conversion document identifies
several examples. But, here, it seems to me that we have a
systemic failure in that, when the conclusion was reached the
CRAM-MD5 was no long appropriate for use, that conclusion didn't
lead directly and in short order to an applicability statement
that said, approximately, "don't depend on that thing" and took
it off the standard track.
If that had been done, and the authors of the "Email submission"
document had recommended it anyway, we would be having a rather
different discussion, don't you think?
john
p.s. For Newtrk/ISD discussion fans, note that, if we had that
mechanism in place, the amount of work that would be required to
deprecate CRAM-MD5 as described above would have been to get
some level of consensus and reissue the ISD with a "not
recommended any more" sentence and a change in status for the
RFC. The level of flexibility anticipated for those documents
is such that it would be reasonable to post an version of the
ISD with that much change and an indication that an explanation
would follow and/or citations to a few published articles and we
could reasonably expect to have such a notice posted formally on
the ISD within a really short time of the IESG decision to
approve the change. By contrast, doing it today requires that
we go though the entire process from I-D to RFC, that the
description of the problems be complete enough for RFC
publication, and that there is no real notice to the typical
implementer until the RFC is published. Maybe worth a little
thought.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf