Re: I-D ACTION:draft-ietf-sasl-crammd5-to-historic-00.txt

[John C Klensin <[e-mail]>]

--On Monday, 24 November, 2008 14:30 -0800
[e-mail] wrote:

> A New Internet-Draft is available from the on-line
> Internet-Drafts  directories.
> This draft is a work item of the Simple Authentication and
> Security Layer Working Group of the IETF.
> 
> 	Title		: CRAM-MD5 to Historic
> 	Author(s)	: K. Zeilenga
> 	Filename	: draft-ietf-sasl-crammd5-to-historic-00.txt
> 	Pages		: 6
> 	Date		: 2008-11-24
> 	
> This document recommends the retirement of the CRAM-MD5
> authentication   mechanism, and discusses the reasons for
> doing so.  This document   recommends RFC 2195 and its
> predecessor, RFC 2095, be moved to   Historic status.

Folks,

While I have no particular attachment to CRAM-MD5 -- Paul,
Randy, and I created it as a service to the community -- I
suggest that you consider this active _very_ carefully.   In
particular (and playing the role of devil's advocate much more
than that of author):

* CRAM-MD5 was designed at a time when the IETF was campaigning
against clear-text passwords on the wire, as a "better than
nothing" alternative.  While its perceived strength has weakened
over the years, it may still have some value in that area.
More important, it did not require cryptography, which was
perceived as an important issue for places and circumstances
where cryptography was prohibited or significantly restricted.

* Empirically, CRAM-MD5 is quite widely deployed and
interoperable.  The claims in this document about the weakness
of the definition notwithstanding, the evidence on the ground is
that people have been able to make it work (possibly by
aggressive application of the robustness principle).  Replacing
it on a flag-day basis ("move this to Historic when SCRAM is
published") with a protocol that has not been similarly tested
and deployed seems to me to be unwise.

* The document appears to suggest that clear-text passwords over
TLS are more desirable than CRAM-MD5.   In a world in which

	 (i) all certificates were anchored in well-established
	and trustworthy CAs and based on more than "responds to
	email" or "has domain" and
	
	 (ii) an in-depth analysis had been done on the ability
	to use partially-known-plaintext attacks (based on the
	very predictable nature of the SMTP, POP, IMAP, etc.,
	session-initiation dialogues) on TLS and a conclusion of
	"no problems" reached

I would certainly agree with that conclusion about clear-text
over TLS if it were substantiated.  However, in a world in which
typical certs for mail servers seem to be either self-signed (or
certified on the basis of email address dialogues or domain name
ownership), in which attacks on the DNS are well-known and the
proper response to "Bind 8 is dead" may be "before or after Bind
4?", methods based on challenge-response may have one advantage
that the I-D does not discuss, namely being independent of the
certificate and DNS situation and relationships.  


* The previous effort to replace CRAM-MD5 with something else
involved an effort to deprecate it in favor of Digest-MD5 which
was argued to be much more secure, etc., etc.   That effort
fizzled out when it became clear that Digest-MD5 had its own set
of problems and that the marginal security benefits were
probably not worth the trouble.  I have not studied SCRAM, but,
absent an RFC-published specification and several years of
experience, I don't have significant reason to believe that, in
practice, it will offer much more marginal benefit over CRAM-MD5
than Digest-MD5 turned out to.   Trying to replace one mechanism
with another involves significant costs, especially to
interoperability as some systems select one of the methods and
others select other ones, so the advantages had better be
significant.

Given all of that, I wonder if denouncing CRAM-MD5 as strongly
as this document seems to is really appropriate.  Would it not
be a lot more sensible and realistic to:

	(i) Publish an updated version of 2195 that reflects at
	more length on the security issues and warnings about
	them?  I note that, given the requirement for two
	interoperable implementations, this document could be
	published at Draft Standard and that there is _no_ bar
	to doing so under the procedures specified in RFC 2026.
	
	(ii) Publish SCRAM and see if it gets any traction in
	practice.
	
	(iii) When, and only if, SCRAM actually does get
	significant deployment in practice, move CRAM-MD5 to
	Historic.

regards,
    john