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

From: Kurt Zeilenga <[email-masked]>
Date: Fri, 1 Aug 2008 10:55:06 +0100

I see the WG as having needs to choose between three possible  
approaches:
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.

It seems to me that what you and others seek is an IESG waiver from  
various requirements placed this technical specification.  It is  
unclear to me whether the IESG which, if any, requirements the IESG  
might be willing to waive in this case.   To to able to even consider  
granting a waiver, they would from us a statement of the specific  
requirements we wish to have waived and why we believe the waiver is  
justified.   I suspect this approach would face a number of challenges  
and is likely to fail.   In particular, 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.  As such, the  
specification would ever be suitable for Draft (or better) status.  It  
seems inappropriate to keep such a specification on the standards  
track.  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 and hence a  
request for waivers based upon such disruption is weak at best.   
Anyways, I ask that those who advocate that certain requirements be  
waived prepare text detail why they should be waived.

I do think it reasonable for those believing the specification fails  
to met requirements placed upon it, enumerate those requirements.   
With that in mind, one requirement I see (off hand) failing to met is  
RFC 4422 mandatory requirement that SASL mechanisms specifications  
precisely specify how character data is to be prepared for input to  
cryptographic to ensure interoperability between implementations of  
the specification.  I do believe there are other requirements.  I  
encourage others to detail them on the list.

I note that little work is needed to accomplish 3 (make the changes  
recently discussed on the list).   2 requires a some amount of work:  
namely documenting the requirements to be waived and why.  1 has no  
support for actually making the changes required under this approach.

-- Kurt

---

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

Kurt Zeilenga wrote on the SASL list:

> issues, such that it is suitable for progression (eventually all
> the way to Internet Standard) on the Standards Track,
> 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
 
> 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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 04 Aug 2008 16:36:45 -0400

> implementation and interop report, now also some years old.

You are beginning to sound inflammatory.

I believe there is a consensus in this WG that CRAM-MD5 in its current form 
is not a meechanism we want people to continue to adopt and deploy, and 
that the best course of action is to document what is already deployed, but 
not give it the imprimatur of an Internet standard, and to move forward 
with other mechanisms which have the properties we desire.  I believe this 
consensus is reflected in the Introduction of the current draft.

You can of course argue within the WG that this is not the best course of 
action, at least until the chairs declare that there is a consensus and the 
issue will not be reopened.  You can also participate in the ongoing 
discussion as to what the next charter should look like.  However, I do not 
expect that the IESG will allow you to ignore that consensus and bypass the 
working group by directly submitting individual work that overlaps the area 
of responsibility of an active working group.

> mechanism instead of "common" I've added a fresher reference.

Again, the prhase "erroneous or intentional lie" is inflammatory and 
unnecessary.  It is also incorrect; the listing in the IANA registry of 
CRAM-MD5 as a "LIMITED USE" mechansim is neither a lie (it is not "an 
intentionally false statement" nor even "a statement intended to deceive"), 
nor even incorrect.  The usage column in the registry describes the 
_intended use_ of the mechanism, not how widely deployed it is.  See 
section 7 of RFC4422.

Further, I would not expect the IANA to honor your request to change the 
intended usage of CRAM-MD5, because entries in that registry may only be 
updated by their owner, and your email address is not <[email-masked]>.

The correct way to change the intended usage of CRAM-MD5 is by obtaining 
consensus for such a change in this working group.  If you cannot obtain 
such a consensus, then requesting a change would be inappropriate.

-- Jeff

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 5 Aug 2008 04:16:21 +0200

Jeffrey Hutzelman wrote:

> I believe there is a consensus in this WG that CRAM-MD5
> in its current form is not a meechanism we want people
> to continue to adopt and deploy

Then the WG is in conflict with its Charter.  It had no
such difficulties with PLAIN.  A promotion on standards
track requires two interoperable implementations, there's
no lack of interoperable CRAM-MD5 implementations.  

The SASL implementation reports posted here so far all
offered CRAM-MD5 among others, and nobody mentioned any
interoperability issues.  Promotion on standards track
is no popularity contest.  Within the limits of what
HMAC is supposed and able to do CRAM-MD5 does this.

> You can of course argue within the WG that this is not
> the best course of action

I'm not more arguing "within" the WG, it's quite clear
that this WG doesn't intend to follow IETF rules as I
understand them.  The WG intends to kick CRAM-MD5 from
the standards track for reasons not stated in RFC 2026,
blocking an in theory simple CRAM-MD5 update for years.

> You can also participate in the ongoing discussion as
> to what the next charter should look like.

I'm mostly interested in the current Charter.  Unless
folks change their mind about deprecating DIGEST-MD5 
I've mentioned one missing point in the current draft.

Wrt SASLprep I've asked if RFC 5198 might be a better
approach.  For SCRAM nobody was interested to look at
RMX as HMAC-alternative, and for HMAC-MD5 folks here
apparently intend to ignore what others said about it.

Apart from that I've nothing to contribute to the next
WG Charter, promoting RFC 4422 is fine.

> I do not expect that the IESG will allow you to 
> ignore that consensus and bypass the working group
> by directly submitting individual work that overlaps
> the area of responsibility of an active working group.

They could decide to follow RFC 2026 and the WG Charter.
There was no much WG activity in the last months.  The
last time something interesting happened (from my POV)
was when HEXA, SCRAM, and YAP were posted (2007-02),
and when DIGEST-MD5 was apparently deprecated (2007-03).

Which was rather harsh after the efforts that went into
2831bis-12, but arguably it was a stop-loss decision.

> "erroneous or intentional lie" is inflammatory

Yes, that's what it is.  And it reflects what I think
about what's going on here wrt CRAM-MD5, an attempt to
block or kill anything that's unrelated to GS2.  It is
fine if folks work on what they are really interested
in, maybe they should get it in the WG Charter at some
point in time.  But what is the purpose of blocking or
killing CRAM-MD5 ?  Were the technical reasons against
DIGEST-MD5 the _real_ reasons to kill 2831bis ? 

> The usage column in the registry describes the 
> _intended use_ of the mechanism, not how widely
> deployed it is.  See section 7 of RFC4422.

Mandatory in several standards, the only incarnation
of a SASL mechanism for ESMTPA in real deployment, and
honourably mentioned in BCP 46.  That *is* as COMMON
as it can get.  More than some other COMMON mechanisms,
notably DIGEST-MD5 if the decision here to deprecate
it holds.  CRAM-MD5 could be an example of a "wildly
successful protocol" in the IAB RFC discussing such
examples.  A bit too simple to qualify as "protocol",
maybe.

> I would not expect the IANA to honor your request to
> change the intended usage of CRAM-MD5, because entries
> in that registry may only be updated by their owner,
> and your email address is not <[email-masked]>.

They'll figure it out and either forward it, or bounce
it, I sent a copy to iesg@ietf.  The owner can confirm
the fix for this classification, or refuse to fix this.

 Frank

---

From: Chris Newman <[email-masked]>
Date: Tue, 05 Aug 2008 11:05:56 -0700

--On August 1, 2008 10:55:06 +0100 Kurt Zeilenga <[email-masked]> 
wrote:
> 2) seek a waiver from the IESG of certain requirements placed upon SASL
> mechanism specifications (such as RFC 4422

The right way to do this is to put text in the document mentioning the rule 
and explaining why it's not being followed in this case.  Then the IETF 
last call and IESG just evaluate the document like any other and are 
approving that text along with the rest of it.

		- Chris

---

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 16 Aug 2008 01:59:27 +0200

Hi, the IANA considerations in the crammd5 draft are
apparently incomplete (= no full RFC 4422 template):

| To: [email-masked]
| Subject: Updated Registration of SASL CRAM-MD5 mechanism.

| SASL mechanism name: CRAM-MD5
| Security considerations: See RFC XXXX
| Published specification: RFC XXXX
| Person & email address to contact for further information:
|      Lyndon Nerenberg <[email-masked]>
|      IETF SASL WG     <[email-masked]>

Suggestion:

| To: [email-masked]
| Subject: Updated Registration of SASL CRAM-MD5 mechanism.

| SASL mechanism name:     CRAM-MD5
| Security considerations: RFC XXXX section 5
| Published specification: RFC XXXX
| Person & email address to contact for further information:
|      Lyndon Nerenberg <[email-masked]>
| Intended usage:          COMMON
| Owner/Change controller: IETF
| Note:                    Replaces RFC 2195

Rationale:  The SASL list is already listed as the default
contact address in RFC 4422 apparently assuming that this
is a persistent institution.

RFC 4422 actually says "owner IESG", but I strongly support
"owner IETF", as the IESG is mostly an administrative tool
of the IETF.  See a note about "IESG approval" in RFC 5226
section 4.1, IMO this detail could be improved in a 4422bis.

The question of the "intended use" was already discussed in
another thread, and IANA informed me that the IESG told them
that the best way to fix this is in a new draft.

 Frank

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 26 Aug 2008 10:13:55 -0700

> apparently incomplete (= no full RFC 4422 template):

I assume this is because I-D is only asking for an update, not  
registering a new mechanism.
I concur that providing a complete registration request would be better.

However, I disagree with much of your suggested content.

> is a persistent institution.

RFC 4422 lists [email-masked] as a place where registrations of  
mechanisms is discussed.  RFC 4422 does not list [email-masked] as  
a "default contact address" for further information about all  
registered SASL mechanisms.  RFC 4422 listed the [email-masked]  
address under the assumption that the mailing list (as opposed to the  
WG) would persist long term.

In the past, the WG has produced some registrations which included the  
WG name/email address (e.g., PLAIN), and others that didn't (e.g.,  
ANONYMOUS).

Personally, I don't care much.  I was just noting that your rationale  
seems flawed.

> section 4.1, IMO this detail could be improved in a 4422bis.

I think we should continue to list IESG <[email-masked]> as the owner  
of all mechanism specifications produced by this WG.  This practice  
appears to be consistent with RFC 4422.   To the extent you think RFC  
4422 should be changed here, I suggest you raise your concerns when  
there is a 4422bis I-D to discuss.

> another thread,

I concur that this question has been discussed within the WG.  That  
discussion has not yet been concluded.  So, with regard to this  
suggestion, I will simply state that the "intended usage" field in the  
registration request (and, of course, any text discussing it) should  
have a value consistent with the WG consensus regarding this question.

-- Kurt