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

[David Hopwood <david.nospam.hopwood at blueyonder.co.uk>]

Tom Petch wrote:
> From "John C Klensin" <john-ietf at jck.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.nospam.hopwood at blueyonder.co.uk>


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf