Re: Client and server authentication for email

--On Sunday, June 12, 2005 4:08 PM -0400 Keith Moore 
<moore(_at_)cs(_dot_)utk(_dot_)edu> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf