Re: Client and server authentication for email

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

 





--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

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