Subject: Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 1 Aug 2008 21:26:25 +0200

Kurt Zeilenga wrote on the SASL list:

> 1) revise the CRAM-MD5 specification, resolving known technical  
> issues, such that it is suitable for progression (eventually all
> the way to Internet Standard) on the Standards Track,
> 2) seek a waiver from the IESG of certain requirements placed upon  
> SASL mechanism specifications (such as RFC 4422 requirement that
> mechanism specifications detail how character data inputs to
> cryptographic functions be precisely specified to ensure
> interoperability), or
> 3) documenting existing CRAM-MD5 practice in an Informational  
> document, noting the known technical issues.
 
> Consensus has been, and continued to be, that fixing known technical
> issues would be too disruptive to existing deployments (which as you  
> note are quite significant).  With this consensus, the third path  
> seems quite appropriate as seems to make no sense to progress a  
> document on the standard track that you wouldn't put on the standards  
> track if considered anew.

Objection:  There are various protocols such as SMTP and HTTP that
would be not "put on the standards track if considered anew" as is,
where they disagree with RFC 2277 and UTF-8.  HTTP has a charming
default Latin-1, while at it overriding MIME text/* in weird ways.

This is a red herring.  RFC 2026 demands maturity, IMO it does not
ask "would you do this again exactly as is now, six years later ?".

RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII.
If implementations do something that is not specified it is their
problem.  If they ignored RFC 2277 and didn't pick UTF-8 for their
choice of "something" they also own the pieces of whatever breaks.

Actually it is now eleven years later, but CRAM-MD5 drafts spent
five years in SASL deliberations, that is no problem in RFC 2195.

> given the WG consensus not to disruptive to deployments of
> CRAM-MD5, the intent seems to be never to revise the 
> specification to met the requirements.

 [quoting the Charter]
| This group will deliver revised Technical Specifications suitable for
| consideration as Draft Standards for the following SASL mechanisms:
| ANONYMOUS, PLAIN, CRAM-MD5, DIGEST-MD5, and EXTERNAL. This work will
| be based upon RFC 2195, RFC 2222, RFC 2831, draft-zeilenga-sasl-anon,
| draft-zeilenga-sasl-plain, draft-nerenberg-sasl-crammd5 and
| draft-melnikov-rfc2831bis, and draft-myers-saslrev-xx.txt.

CRAM-MD5 is about as simple as it can get, and as RFC 2195 does
not mention what to do with the 8th bit the normal approach in
RFC 2277 "let's take UTF-8" will work as expected.  Limiting it
to whatever other SASL mechanisms do (at the moment *in theory* 
SASLprep) is no issue, US-ASCII is a proper subset of SASLprep.

In practice RFC 5198 might be a better approach, and once again
US-ASCII is a proper subset of Net-UTF8 (NFC with minor twists).

> It seems inappropriate to keep such a specification on the
> standards track.

2026bis is fortunately no deliverable of the SASL WG, what it's
supposed to deliver is a DS for CRAM-MD5.  If the SASL WG does
not more wish to do what it was chartered to do, or maybe never
intended to do what it was chartered to do, the existing draft
can be promoted outside of a WG (2821bis + 2822upd just pulled
that, it is not impossible).  After five years the draft has
reached its own kind of maturity.  I have implemented its i18n
example four years ago.  The draft is mentioned in a CRAM-MD5
implementation and interop report, now also some years old.

In the request sent to IANA to fix the <quote> erroneous or
intentional lie <unquote> listing of CRAM-MD5 as "limited use"
mechanism instead of "common" I've added a fresher reference.

> Another challenge is that the RFC 2026 specifically warns  
> deployments of Proposed Standard specifications of the
> likelihood that subsequent revision will be disruptive to
> deployers

Yes, if some implementation insists on say KOI8-R instead of
an appropriate style of UTF-8 it owns the pieces, see above.
This was not specified, above a broad hint at RFC 822, and
there is no KOI8-R in RFC 822.

> I do believe there are other requirements.

I doubt it.  CRAM-MD5 is at a similar level of complexity as
PLAIN adding HMAC.  Being better than "pseudo-PLAIN" (PLAIN
outside of SSL), or APOP, or "LOGIN" is the whole purpose of
CRAM-MD5.  That CRAM-MD5 is also "better" than DIGEST-MD5 in
a certain sense was no design goal, it just happened as side
effect of KISS.

 Frank

_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 19:52:44 -0700

> ask "would you do this again exactly as is now, six years later ?".

I would argue that what RFC 2026 demands specifications which  
developers can independently produce interoperable implementations from.

When I said "considered anew", I didn't mean "would we do this again  
exactly as we before".  What I mean was that a document shouldn't get  
a bye from currently in place requirements simply because it was  
originally engineered before those requirements were in place.   And  
while we do now have a "use UTF-8" requirement in IETF protocols, that  
doesn't necessarily mean that non-UTF-8 character data fields in  
fields should be respecified as carrying UTF-8 character data.   There  
are other approaches for providing internationalization in existing  
protocols (such as taken in IDN), and then there is the approach of  
replacing the old protocol with a new protocol that has adequate  
internationalization.

While my discussion above utilizes i18n issues, the I-Ds failure to  
met requirements placed upon it are not believed to be limited to i18n  
issues.

> choice of "something" they also own the pieces of whatever breaks.

I see reason why an implementor of RFC 2195 would read RFC 2277, and  
if they did, why they would take its statements as imparting any  
requirement upon implementations of any protocol.   RFC 2277  
discussions requirements upon technical specifications produced by the  
IETF, not requirements upon implementors of IETF produced technical  
specifications.

> five years in SASL deliberations, that is no problem in RFC 2195.

I believe the WG consensus is that there are significant problems with  
RFC 2195.

> supposed to deliver is a DS for CRAM-MD5.

That's what it was chartered to delivered.   The WG consensus seems  
not to attempt to met all the requirements for draft standard here.   
One could argue given this, the WG should simply abandon its work to  
date.  However, it seems quite reasonable for the WG to offer what it  
has done to date for publication on the track it finds most suitable.

-- Kurt

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 11 Aug 2008 20:18:28 -0700

On 11 Aug 2008, at 7:52 PM, Kurt Zeilenga wrote:

> discussions requirements upon technical specifications produced by  
> the IETF, not requirements upon implementors of IETF produced  
> technical specifications.

s/see/see no/

Sorry, Kurt