--On Thursday, 07 September, 2006 14:31 -0700 "Kurt D. Zeilenga"
<Kurt@xxxxxxxxxxxx> wrote:
> At 01:36 PM 9/7/2006, John C Klensin wrote:
>> Actually, that topic opens up one of the fundamental issues
>> with our standards process ... one where better definition
>> and clear community consensus is, IMO, needed. Measured by
>> our documented criteria, 2195 exists in multiple independent
>> implementations, has been widely deployed, and is considered
>> useful by many of those who are using it.
>
> In addition to security concerns, it must be stated that
> implementations of RFC 2195 suffer from interoperability
> problems due to its failure to specify a character set/encoding
> and normalization/preparation algorithm for the password
> string.
>
> The WG decided it was better to document current
> implementations of CRAM-MD5 than to rework CRAM-MD5 to address
> these and other issues, and to do so on the Informational
> track.
>
> If you have something new to add to the discussion of revision
> approach taken within the SASL WG, you (and others) are
> welcomed to comment on the SASL WG list. The document will be
> in WG Last Call soon.
Kurt,
I think we have a small misunderstanding here. Let me say more
clearly and briefly what I tried to say in a prior note with
regard to the substance of the CRAM-MD5 spec:
* I have basically lost interest in CRAM-MD5. They
were never important to me except as a "no
infrastructure, better than plain text" demonstration,
I'm not using them now, etc. So I wish the SASL WG the
very best with whatever you decide to do with it.
* There is a more general principle about how we define
and process maturity levels for which 2195 may or may
not be a good example. That one has to do with whether
a specification is good enough for interoperable
implementations and whether people care to create those
implementations. It also has to do with whether one
needs to bring every old document up to ever-rising
contemporary standards before approving it. My note was
really addressed to that principle and not to 2195
and/or the SASL WG.
The second issue is closely related to some issues that Newtrk
took a careful look at and, arguably, reached some measure of
consensus about. And that is where this thread started.
Now, having made that observation, one more comment: It is, as
far as I'm concerned, perfectly reasonable for the SASL WG to
say "CRAM-MD5 is too weak for use today and is badly designed
for SASL use because it assumed net-ASCII rather than addressing
internationalization and other character sets" and then either
ignore it completely as a SASL method, document a SASL CRAM-MD5
as informational, or repeat the recent stunt of having a
specification published as initially historic.
However, 2195 is not, itself, a SASL method and there is nothing
in the procedural rules as I understand them that permits the
SASL WG to de-standardize it (you could write any of several
styles of document that would designate it as "not recommended"
or even "historic" but such documents had best be in your
Charter and Last Called as doing that).
Now, suppose someone comes along who _likes_ the non-SASL
incarnation of CRAM-MD5 in 2195. Let's call this hypothetical
person "nobody" to avoid casting aspersions on Frank. Nothing
in our current procedures prevents him, at any time, from
preparing an interoperability report on 2195-specified CRAM-MD5,
pointing out that there are many deployed interoperable
implementations, and asking that 2195 be reclassified (or a
2195bis be published) as a Draft Standard. If "nobody" were so
inclined, I would expect him to protest any effort on the part
of the SASL WG to deprecate 2195 itself and to appeal any
decision to block the advancement of 2195[bis] to Draft Standard
if that decision involved either the SASL WG's work (at least
unless the WG gets a charter item to write an Applicability
Statement for 2195 and starts serious work on it) or the
assertion that CRAM-MD5 was not up to today's requirements for
the public Internet. I wouldn't join "nobody" in putting
significant work into those efforts because I don't care
enough... although I might get excited about the principles if
it came to an appeal.
best,
john, sometime procedural troublemaker
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf