Tom Petch wrote:
From "John C Klensin" <john-ietf(_at_)jck(_dot_)com>:
(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.
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 am all in favour of usable security. All too often, however, "ease-of-use"
is used to justify security compromises, without even thinking about how a
higher level of security and a better user interface could be achieved
simultaneously. That is *not* sound engineering.
I apply the same logic to MD5.
We know how to design password-based protocols that prevent session hijacking
and dictionary attacks, provide mutual authentication, and do not require
storing password-equivalent authenticators. It is not rocket science,
and it does not require any additional effort from the user. That's not
the problem; the problem is a lack of *concrete* deployable security
protocols that implement the known state of the art.
(TLS prevents session hijacking, but does not implement strong password
authentication. AFAIK, the nearest thing available is
<http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-09.txt>.)
--
David Hopwood
<david(_dot_)nospam(_dot_)hopwood(_at_)blueyonder(_dot_)co(_dot_)uk>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf