<inline> Tom Petch ----- Original Message ----- From: "John C Klensin" <john-ietf@xxxxxxx> To: "Brian E Carpenter" <brc@xxxxxxxxxxxxxx>; "Keith Moore" <moore@xxxxxxxxxx> Cc: <ietf@xxxxxxxx>; <iesg@xxxxxxxx>; "Dave Crocker" <dcrocker@xxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf