Subject: Response to Frank Ellermann's appeal

From: <[email-masked]>
Date: Wed, 3 Sep 2008 15:31:25 +0300

1. Background

On 2008-08-11, Kurt Zeilenga, co-chair of SASL WG, posted a message
(http://www.imc.org/ietf-sasl/mail-archive/msg03204.html):

> I believe there is consensus within the WG that RFC 2195 failed to
> adequately specify how character data inputs, in particular the
> shared secret, are to be encoded and prepared for input to
> cryptographic functions and this has lead to interoperability
> problems.  Your input was considered by the WG, but not found to be
> compelling.

Later on the same day, Frank Ellermann posted a reply
(http://www.imc.org/ietf-sasl/mail-archive/msg03204.html).

In his email, Frank argues that RFC 2195 only specifies the use of
ASCII passwords (and possibly other strings), and if some
implementations have allowed the use of non-ASCII characters, they
have implemented something that's not in the specification.

In the end of his email, Frank writes:

> I appeal that decision.  As remedy I propose to issue an IETF 
> Last Call of the CRAM-MD5 draft on standards track.

There were off-list emails clarifying that this was intended as an
appeal to the Area Director. Since the topic has been discussed with
the WG chairs before, without being resolved to Frank's satisfaction,
an appeal to the AD is possible.

2. Summary

Frank's appeal raises the following objection:

The WG chair (Kurt Zeilenga) was incorrect to declare rough WG
consensus on RFC 2195 having interoperability problems.  In Frank's
opinion, RFC 2195, as specified in the RFC, does not in fact have
interoperability problems, and any interoperability problems would be
due to implementing undocumented functionality beyond RFC 2195. He
also believes that sufficiently many other WG members share this
opinion, so declaring rough WG consensus was incorrect.

In subsequent off-list emails, it has been clarified that the
following topics are not in the scope of this appeal:

- Whether draft-ietf-sasl-crammd5 should be published as
  Informational, Proposed Standard, Draft Standard, or Historic.
  While interoperability can be one consideration related to this
  question, other factors need to be considered as well.  Also, there
  is still ongoing WG discussions about this topic, so a process
  appeal (claiming consensus was incorrectly declared) or a
  substantive appeal (claiming the decision is wrong) would be
  premature.

- Whether implementations of draft-ietf-sasl-crammd5, which adds
  support for non-ASCII characters, are likely to have
  interoperability problems.

- Whether implementations of draft-ietf-sasl-crammd5 are likely to
  have interoperability problems with existing implementations of 
  RFC 2195.

- Whether CRAM-MD5 is "secure enough", or more/less preferable 
  or secure than some other SASL mechanisms.

3. Background research

When digging deeper to this topic, I found a number of things that,
while they're not directly related to Kurt's email on 2008-08-11, may
have partly contributed to the situation:

- Discussions about CRAM-MD5 have spread over a long time. I 
  browsed through the archives for past two years, and had hard 
  time getting a good picture of the situation (e.g. I couldn't 
  even find a message summarizing the results of the March 2007
  WG last call).

- The WG charter is badly out of date, and apparently hasn't really
  reflected reality in a long time. Also, the proposed new charter 
  text (from February 2008) didn't even list CRAM-MD5 at all, and
  even after reading the mailing list archive, it wasn't quite
  clear whether this was intentional or not.

- In his email on 2008-08-27, Kurt explained that when he wrote "I
  believe there is consensus.." (on 2008-08-11), his intent was to
  test this belief by stating it, not to declare WG consensus and
  close discussion. This distinction could have been phrased in a
  clearer way, and I find it plausible that some WG members did not
  read it this way.

Furthermore, it's not quite obvious that we even *need* WG consensus
on the specific question raised by Frank.  For draft-ietf-sasl-crammd5, 
IMHO it's valuable to document what existing widely used CRAM-MD5
implementations have done, even if their behavior varies and isn't
ideal by today's standards.  Documenting that behavior doesn't
necessarily require us to agree on whether the implementations were
strictly following RFC 2195 or not. This particular question also
does not determine the intended status of the document.

4. Decision

I did not find sufficient information to clearly determine whether
Kurt's statement about rough consensus, if interpreted as declaring
consensus, would be incorrect or not. It's possible that the
information exists, but is just spread over too long time for me to
find. Given this, and Kurt's clarification on 2008-08-27 that his
intent was not to declare WG consensus, I do not believe any specific
AD action to remedy the situation is needed.

(Also, the remedy suggested by Frank -- "issue an IETF Last Call of the
CRAM-MD5 draft on standards track" -- does not seem to be appropriate,
given that the discussion about the ongoing status is still ongoing.)

5. Additional Suggestions

Although my decision is not to mandate any particular remedy for this
appeal, it's also clear that draft-ietf-sasl-crammd5 hasn't been
progressing well lately, and it's not a good example of how we'd like
the IETF WG process to work. 

Instead of digging more deeply to the archives to figure out who said
what, I think we need to concentrate on getting the document ready and
shipped soon. This has been dragging on too long, and I guess we're
running out of steam for this work item. Thus, I'd like to make the
following suggestions for the WG to consider. These suggestions are
something I probably should have made before this mess turned into
an appeal, and they're not directly to the topic being appealed.

1) WG chairs: I believe it would be useful to post a message
summarizing the WG members' opinions on draft-ietf-sasl-crammd5: who's
happy with progressing the document basically as-is, and who is not?
And for the folks in the latter group, what *specific* changes would
make them to change their mind? (If you do not have the information
needed here, it would suggest that another WGLC could be helpful.)

For the question of intended status, it would be useful to know more
than binary opinions (e.g. "I prefer X but could live with Y" or "both
X and Y work for me"). If you don't have accurate information about
the current opinions, a straw poll might be useful to gather them
(explicitly giving flexible options like thes listed above).

Based on this, I think it would be useful to propose some kind of plan
for moving forward. I'd be fine with almost any plan that gets us to
completion within reasonable time (the milestone was 2 years ago), and
doesn't require the WG to come up with huge amounts of new energy for
this work item (which doesn't look very likely).

For the record: if there is rough WG consensus that the document is
appropriate for Standards Track, I am willing to send it to IETF last
call and IESG evaluation for Standards Track. Even though CRAM-MD5 is
not perfect by any means, it is widely deployed and used, and IMHO
it's valuable to have an up-to-date document describing it. My
personal preference might be more towards Informational, but I can
live with Standards Track, too, if that gets the document published.

The last call and IESG evaluation may, of course, result in the IESG
deciding that a different category is more appropriate. Also, since
the draft adds new non-trivial functionality to RFC 2195 (which isn't
covered by implementation reports of RFC 2195, I presume), if it's
going to be on Standards Track, it probably should be recycled at
Proposed Standard instead of being moved to Draft Standard.

2) To WG chairs and all WG members: Please get rough consensus on
updated SASL WG charter, which either includes CRAM-MD5 as a WG item
(and says something about it), or intentionally drops it, and submit
it to new IESG/IAB review (and eventually public review) as soon as
possible. Preferably within a couple of weeks.

3) To all WG members: No amount of tweaking will make CRAM-MD5 
perfect -- and its been dragging on too long already -- so I would not
recommend spending lot of energy on it. It's valuable to document
existing widely deployed protocols, but once that's done to "good
enough" level, I think getting other documents, like the DIGEST-MD5
successor and GS2, ready, would be better use of our time.

Best regards,
Pasi