ietf
[Top] [All Lists]

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

2005-06-12 11:27:28
<inline>
Tom Petch
----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: "Brian E Carpenter" <brc(_at_)zurich(_dot_)ibm(_dot_)com>; "Keith Moore" 
<moore(_at_)cs(_dot_)utk(_dot_)edu>
Cc: <ietf(_at_)ietf(_dot_)org>; <iesg(_at_)ietf(_dot_)org>; "Dave Crocker" 
<dcrocker(_at_)bbiw(_dot_)net>
Sent: Saturday, June 11, 2005 6:07 AM
Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP


<snip>

(2) CRAM-MD5 was designed around a particular market niche and,
based on the number of implementations and how quickly they
appeared, seems to have responded correctly to it.  It may be
appropriate at this point to conclude that market niche has
outlived its usefulness, but if "The RECOMMENDED
alternatives..." include only things that are significantly more
complex or require significantly more infrastructure, there is
some reason to believe that they will go nowhere fast,
independent of any pronouncements the IETF chooses to make.

     john


I am reminded of the following from secsh-architecture, in the context of how to
check the ssh host public key, and so authenticate the ssh host.

" The members of this Working Group believe that 'ease of use' is
   critical to end-user acceptance of security solutions, and no
   improvement in security is gained if the new solutions are not used.
   Thus, providing the option not to check the server host key is
   believed to improve the overall security of the Internet, even though
   it reduces the security of the protocol in configurations where it is
   allowed."

For me, this is sound engineering, imperfect but recognising the frailties of
the world,
producing something that will be deployed.  I apply the same logic to MD5.



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



<Prev in Thread] Current Thread [Next in Thread>