Subject: what happened to newtrk?

From: Eliot Lear <[email-masked]>
Date: Tue, 05 Sep 2006 16:39:05 +0200

All,

As a participant in the newtrk working group and someone who actually
ran one of the only reasonably successful experiments in that group, I
think the community is owed a better accounting of why WG failed, and
that steps should be taken to see that such efforts do not fail in the
future.  The newtrk working group was chartered to revise the standards
track, with an understanding that the current one is demonstrably not
working as it should.  As I've previously mentioned, few if any
specifications get to draft or full standard, and no review of PS had
ever been done along the timelines specified in RFC 2026.

Numerous proposals were made within the working group.  The ISD proposal
seemed to be the one that had the most support.  However, this proposal
ran into stiff opposition within the IESG and was effectively killed. 
We can argue until the cows come home as to whether or not the ISD
proposal was ready for prime time.  However, the end result was that we
had a working group chartered to do a specific task, do the task, and
then have the work rejected.  Quite frankly we don't have the resources
to have that happen.  I suspect anyone who had any involvement with that
group will be extremely reticent to work on process proposals in the
future, because they will assume that any given IESG is likely to reject
any output.

What I would like to know is what we could have done to prevent this
from happening.  Was the newtrk charter not sufficiently narrow to
accomplish a task for which there was community consensus?  Is a working
group the appropriate place to make process changes?  I am leaning
heavily toward "no" on that last one.  Should the IESG simply both
propose and dispose?  Perhaps the IAB has a role of proposing changes.

Eventually, as I wrote in a previous note, we must circle back and
actually fix the standards process to reflect reality.  But how that is
to be done remains to me an open question.

Eliot

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "todd glassey" <[email-masked]>
Date: Tue, 5 Sep 2006 08:19:00 -0700

Eliot - the problem quite simply is that the IESG needs to be disbanded. It
serves no other purpose than to complicate the creation and acceptable
vetting models for Internet Standards and as such really needs to be a thing
of the past - The standards process is easily updated to remove the IESG
from the process and since they are not chartered to protect the Internet
their existence at all is unwarranted overhead and control of political
issues within the Internet as a whole and as such totally inappropriate
anymore.

2 cents.

T

---

From: Keith Moore <[email-masked]>
Date: Tue, 05 Sep 2006 12:33:45 -0400

> issues within the Internet as a whole and as such totally inappropriate

s/the IESG/Todd Glassey/g

Keith

---

From: "todd glassey" <[email-masked]>
Date: Tue, 5 Sep 2006 10:03:01 -0700

Kieth - abusive language for the purpose of being abusive is prohibited on
these lists. Take this as a formal complaint to the Chair over this action.

Todd Glassey

---

From: "todd glassey" <[email-masked]>
Date: Tue, 5 Sep 2006 10:03:01 -0700

Todd Glassey

---

From: Keith Moore <[email-masked]>
Date: Tue, 05 Sep 2006 13:10:26 -0400

Now Todd, you must admit that this is true.  You are no more chartered 
to protect the Internet than IESG is.  So why isn't your existence here, 
by your own criteria, unwarranted overhead?

Keith

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 5 Sep 2006 21:49:38 -0700 (PDT)

On Tue, 5 Sep 2006, Eliot Lear wrote:
> then have the work rejected.

>From my perspective as an outsider, I have to say that I was
extremely disappointed that the WG spent the bulk of its time on
"the creation of a new series of short IESG-approved IETF documents
to describe and define IETF technology standards" rather than
concentrating on redefining the standards track.

> accomplish a task for which there was community consensus?

Having just re-read the charter, I would have to say so.  I think we
would have been better served if the WG had been given the much less
ambitious task of producing an update of RFC 2026 that describes what
we actually do.

> to be done remains to me an open question.

Well, one possibility might be to charter a design team or WG to do
just that -- i.e., to take the term "Best Current Practice" at face
value and produce of a standards process BCP that actually documents
current practice.

//cmh

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Sep 2006 10:58:16 +0200

Eliot Lear wrote:

> few if any specifications get to draft or full standard,
> and no review of PS had ever been done along the timelines
> specified in RFC 2026.

Okay, let's nail this, I like to see 2195 and 3464 as DS,
what exactly can I do ?

> Numerous proposals were made within the working group.

Bert's idea was nice, establish a timeout for PS, and after
that time move the PS automatically to historic.  Of course
we'd need a long transitional period for the PS not covered
by "decruft".

> What I would like to know is what we could have done to
> prevent this from happening.

Don't try to replace the "three stage" process because it's
in essence good.  The detail where the IESG is supposed to do
the whole work apparently needs fixing.

Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Sep 2006 11:56:55 +0200

> Okay, let's nail this, I like to see 2195 and 3464 as DS,

3464 is already DS according to the RFC Index.

For 2195, write and publish an interoperability report, and

if {all mandatory and optional features shown to interoperate}
     then {send a request to reclassify RFC 2195 to the IESG}
     else {publish a draft-ellermann-2195bis with non-interoperable features removed};
          {send a request to approve it as DS to the IESG}

It's better if you find a willing AD first, and work with him or her instead
of the IESG as group.

    Brian

---

From: <[email-masked]>
Date: Wed, 6 Sep 2006 13:35:30 +0300

Brian,

Your description of the process omitted the most 
time-consuming part: 

for {each normative reference}
     if {at lower maturity level AND downref acceptable}
     then {write justification why downref is acceptable}  
     else {repeat process recursively to bring reference to DS}

A while ago Tero Kivinen wrote a script for automatically finding 
the required documents; according to the script, to bring IPsec to 
DS you'd need to upgrade somewhere between 70 and 400 (if I recall
correctly) documents. (The number is fuzzy because older documents 
didn't separate normative and informative references. And some of 
those references could be justified as acceptable downrefs or 
re-classified as informative.) 

Whatever the correct figure is (it's anyway dozens of documents), 
it's also quite obvious that nobody will ever do the process.

For RFC 2195 (an extension to IMAP), you'd probably need to bring 
IMAP to DS first.

Best regards,
Pasi

> -----Original Message-----
> From: ext Brian E Carpenter [mailto:[email-masked]] 
> Sent: 06 September, 2006 12:57
> To: Frank Ellermann
> Cc: [email-masked]
> It's better if you find a willing AD first, and work with him 
> or her instead of the IESG as group.
> 
>     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Sep 2006 13:15:24 +0200

Pasi,

That's correct. But as you presumably know, RFC 3967
offers a way of dealing with that problem. See
http://www1.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
for results so far.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Sep 2006 13:24:26 +0200

> ambitious task of producing an update of RFC 2026 that describes what

What we actually do is a one step process.  Let us accept for purposes
of argument that a three step process is good, as Frank Ellermann
suggests.  If we want to make it functional something has to change, and
that means not describing what we actually do.  All of this having been
said, I'll repeat that I'm fine with a BCP to update 2026 to allow down
references, if that clears the logjam.

> value and produce of a standards process BCP that actually documents

I think the IESG has to take a FAR more active role in any such effort
to avoid a repeat of the failure.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Sep 2006 13:24:26 +0200

Eliot

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 06 Sep 2006 12:34:00 +0100

Brian E Carpenter wrote:

> For 2195, write and publish an interoperability report,

SASL WG is revision it (draft-ietf-sasl-crammd5-07.txt).
And no, this document is not going to make it to DS due to security 
concerns.

> and

>For RFC 2195 (an extension to IMAP), you'd probably need to bring 
RFC 2195 predates formalization of the SASL framework (RFC 2222, 
recently replaced by RFC 4422).
These days one has to bring RFC 4422 to DS instead. However this point 
is moot due to the comment above.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Sep 2006 13:35:40 +0200

> 3464 is already DS according to the RFC Index.

Good, the process works, unlike my memory:  I meant 3834,
a few days ago I wrote 3864 instead of 3834 on another
list, so that's the third attempt: 3834.

 [interoperability report]
>    then {send a request to reclassify RFC 2195 to the IESG}

So far it sounds simple (for the 2195 example).  I test it,
thanks for info.

Frank

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Sep 2006 16:36:35 -0400

> So far it sounds simple (for the 2195 example).  I test it,

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.   Current thinking in the security area
is that it isn't much better than the use of clear-text
passwords, but our formal definitions of the requirements for
Draft Standard don't require that we recommend the use of the
protocol involved: "Draft" and "Not Recommended" are perfectly
consistent.

It would also be completely consistent with our published
policies to require that a Draft Standard offspring of 2195
contain explicit text in the Security Considerations section
that describes the attack, recommends that the technique of 2195
be used only over an encrypted tunnel or on a protected network,
reflects on whether it offers any real advantage over plain text
passwords in those situations, and recommends something else.  

It is not consistent with our published policies as I read them
to refuse to promote it to Draft simply because there is general
feeling that security technology has passed it by.  But that is,
I think, exactly what would happen today if the protocol were
proposed for advancement.

        john

p.s. While I'm the first-listed author of 2195, I don't hold any
particular affection for it.   It was written because it seemed
to be necessary at the time and I could pull a group together to
do the work.   The comments above are hence independent of any
personal interest in keeping 2195 alive -- I have none.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 07 Sep 2006 14:31:02 -0700

At 01:36 PM 9/7/2006, John C Klensin wrote:
>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, SASL WG co-chair

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 00:13:33 +0200

John C Klensin wrote:
 
> that topic opens up one of the fundamental issues with our
> standards process ... one where better definition and clear
> community consensus is, IMO, needed.

"Fundamental" and "consensus" sounds dangerous, see subject.

> 2195 exists in multiple independent implementations, has been
> widely deployed, and is considered useful by many of those
> who are using it.

Yes, easy to implement, better than PLAIN (outside of TLS).

> Current thinking in the security area is that it isn't much
> better than the use of clear-text passwords

Maybe they'll prove this in an understandable way, or offer it 
as their opinion.  I could also offer an opinion about 6 to 10
parameters of DIGEST-MD5, its RFC 2069 fallback under certain
(TBD) conditions, the proposed backslash canonicalization, etc.

> the requirements for Draft Standard don't require that we
> recommend the use of the protocol involved: "Draft" and "Not
> Recommended" are perfectly consistent.

Good, let's keep say STD 20 as is, all its about 57 lines. :-)

Frank

http://purl.net/xyzzy/home/test/cram.xml

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Sep 2006 19:07:51 -0400

--On Thursday, 07 September, 2006 14:31 -0700 "Kurt D. Zeilenga"
<[email-masked]> 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. 
> 
> 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.
> 
> 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

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 01:08:02 +0200

> problems due to its failure to specify a character

The challenge has the syntactical form of an RFC 822 msg-id.

The concepts of userid and password are the business of the
application.  All CRAM-D5 needs is "no SPACE in the userid",
for a SPACE as defined in (say) RFC 822.  No rocket science.

> implementations of CRAM-MD5

Some related URLs for those who don't read this list:

http://permalink.gmane.org/gmane.ietf.sasl/2079
http://permalink.gmane.org/gmane.ietf.sasl/2084
http://permalink.gmane.org/gmane.ietf.sasl/2086
http://permalink.gmane.org/gmane.ietf.sasl/2360
http://permalink.gmane.org/gmane.ietf.sasl/2389

The only issue I can detect is that forcing shepherds to vote
YES when they prefer ABSTAIN would make no sense.  We had a
similar discussion here on this list wrt draft-hutzler-spamops.

Frank

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Sep 2006 19:48:45 -0400

> Charter and Last Called as doing that).

To the extent that SASL is the successor to the original extensible 
authentication framework contained in IMAPv4, yes, CRAM-MD5 is a SASL 
mechanism.  The cross-references don't explicitly point out that RFC2222 
obsoletes RFC1731, but it seems clear that was the intent.

> 2195bis be published) as a Draft Standard.

Well, he could ask that 2195 be advanced as-is, but I would expect such an 
effort to fail, as that version has turned out to be somewhat 
underspecified.  Multiple interoperable implementations is not the _old_ 
criteria for advancement; it is necessary but not sufficient(*).

Given that the SASL WG has an explicit charter item to produce a revised TS 
for CRAM-MD5, with RFC 2195 as a starting point, I would expect any effort 
to do so outside of that WG to meet with very strong resistance.  As Kurt 
has noted, the WG is nearly finished its work on that item, and the 
resulting draft will be in Last Call soon.

The working group decided, due to a variety of considerations, not to 
pursue publication of the new document on the standards track, and instead 
to ask that it be published as Informational.  However, the decision as to 
whether to publish that document and what status to assign it belongs to 
the IESG, not the working group.  IMHO, an argument that it should be 
assigned a status other than that requested by the working group would be 
an appropriate subject for a Last Call comment.

 If "nobody" were so
> of the SASL WG to deprecate 2195 itself

Why?  That working group's charter clearly includes an item to produce an 
updated specification for CRAM-MD5, and it seems obvious that the intent is 
that such a new specification obsolete RFC 2195 (if it's not obvious, 
that's a bug in the charter; certainly everyone participating in the work 
has understood that to be the intent).

(*) I think this is perhaps the crux of the matter.  I do not believe that 
every old specification should be advanced along the standards track simply 
because it has been around a while and has multiple implementations. 
Advancing a specification to Draft Standard sends the signal that the IETF 
thinks the specification is a good idea and that people should deploy it. 
Protocols for which that is not the case have no business advancing toward 
the status of Internet Standard, *even if we thought they were good ideas 
when they were written*.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Sep 2006 20:11:43 -0400

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> Actually, that topic opens up one of the fundamental issues
    John> with our standards process ... one where better definition
    John> and clear community consensus is, IMO, needed.  Measured by
    John> our documented criteria, 2195 exists in multiple independent
    John> implementations, has been widely deployed, and is considered
    John> useful by many of those who are using it.  Current thinking
    John> in the security area is that it isn't much better than the
    John> use of clear-text passwords, but our formal definitions of
    John> the requirements for Draft Standard don't require that we
    John> recommend the use of the protocol involved: "Draft" and "Not
    John> Recommended" are perfectly consistent.

John, in principle I agree with you, but I'll point out there is a
huge lack of clarity around ASes.  It's hard for example to find ASes
for a given TS, and it would confuse people if something were a draft
standard and not recommended at the same time.  This is particularly
true given factors such as the rfc-index only lists the position along
the standards track, not the requirements level of the associated AS.

I would be all for draft but not recommended if we got to a point
where the users of our documents would understand what that meant.
I'm all for experiments--even ISD-like experiments--in organizing our
metadata and descriptions of standards so people could get these
points.  I don't have time to work on those experiments myself and so
until they succeed my preference is to be conservative.

    John> It is not consistent with our published policies as I read
    John> them to refuse to promote it to Draft simply because there
    John> is general feeling that security technology has passed it
    John> by.  But that is, I think, exactly what would happen today
    John> if the protocol were proposed for advancement.

OK.  I read RFC 2026 as giving the IESG the latitude to make a
judgment of the technical quality of a protocol (and the TS) when
advancing along the standards track.  I'd always assumed that the IESG
should iFrom [email-masked] Thu Sep 07 20:17:33 2006
From: Sam Hartman <[email-masked]>
To: John C Klensin <[email-masked]>
Date: Thu, 07 Sep 2006 20:11:43 -0400
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: what happened to newtrk?

>>>>> "John" == John C Klensin <[email-masked]> writes:

    John> Actually, that topic opens up one of the fundamental issues
    John> with our standards process ... one where better definition
    John> and clear community consensus is, IMO, needed.  Measured by
    John> our documented criteria, 2195 exists in multiple independent
    John> implementations, has been widely deployed, and is considered
    John> useful by many of those who are using it.  Current thinking
    John> in the security area is that it isn't much better than the
    John> use of clear-text passwords, but our formal definitions of
    John> the requirements for Draft Standard don't require that we
    John> recommend the use of the protocol involved: "Draft" and "Not
    John> Recommended" are perfectly consistent.

John, in principle I agree with you, but I'll point out there is a
huge lack of clarity around ASes.  It's hard for example to find ASes
for a given TS, and it would confuse people if something were a draft
standard and not recommended at the same time.  This is particularly
true given factors such as the rfc-index only lists the position along
the standards track, not the requirements level of the associated AS.

I would be all for draft but not recommended if we got to a point
where the users of our documents would understand what that meant.
I'm all for experiments--even ISD-like experiments--in organizing our
metadata and descriptions of standards so people could get these
points.  I don't have time to work on those experiments myself and so
until they succeed my preference is to be conservative.

    John> It is not consistent with our published policies as I read
    John> them to refuse to promote it to Draft simply because there
    John> is general feeling that security technology has passed it
    John> by.  But that is, I think, exactly what would happen today
    John> if the protocol were proposed for advancement.

OK.  I read RFC 2026 as giving the IESG the latitude to make a
judgment of the technical quality of a protocol (and the TS) when
advancing along the standards track.  I'd always assumed that the IESG
should include factors like security in that determination--not just
interoperability.  Heck, I even assumed it was reasonable to have a
higher bar for spec clarity at DS than PS.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Sep 2006 20:10:33 -0400

On Thursday, September 07, 2006 07:48:45 PM -0400 Jeffrey Hutzelman 
<[email-masked]> wrote:

> Well, he could ask that 2195 be advanced as-is, but I would expect such
> an effort to fail, as that version has turned out to be somewhat

Ugh.
s/_old_/_only_/

nclude factors like security in that determination--not just
interoperability.  Heck, I even assumed it was reasonable to have a
higher bar for spec clarity at DS than PS.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Sep 2006 20:10:33 -0400

Ugh.
s/_old_/_only_/

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 07 Sep 2006 17:09:05 -0700

At 04:07 PM 9/7/2006, John C Klensin wrote:
>clearly and briefly 

My message was intended to clarify why the SASL WG is
pursuing an Informational recommendation for its RFC2195bis
work and to redirect any comments specific to this work to
the WG's list.

As it was not my intent to participate in the general
discussion of "fundamental issues with our standards process"
you raise (which is why I changed the subject), and your
follow-up is in the same vein, I won't comment further.

-- Kurt

---

From: Christian Huitema <[email-masked]>
Date: Thu, 7 Sep 2006 17:25:19 -0700

> From: Kurt D. Zeilenga [mailto:[email-masked]]

Well, if I remember correctly, there was ample discussion of this topic
during the IETF meeting in Paris -- both Steve Bellovin and I presented
the issues with such techniques. Basic challenge response mechanisms
like CRAM-MD5 are simply too weak to be used on the Internet. They are
subject to dictionary attacks, which can retrieve the password in a very
short time. They don't deserve much more than documentation for
historical purpose.

-- Christian Huitema

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 03:44:09 +0200

Jeffrey Hutzelman wrote:
 
> Multiple interoperable implementations is not the
[only]
> criteria for advancement; it is necessary but not
> sufficient

2026 says "mature, useful, well-understood, stable."
A downref to SASLprep for a 2195bis DS would be odd,
in that case better publish 2195bis as PS.

> The working group decided, due to a variety of
> considerations, not to pursue publication of the
> new document on the standards track, and instead
> to ask that it be published as Informational.

That's the case "informational obsoletes PS".  How's
that supposed to work wrt BCP 46, ACAP, and ODMR ?

> an argument that it should be assigned a status other
> than that requested by the working group would be an
> appropriate subject for a Last Call comment.

Yes.  That solves also Sam's problem, he can change his
vote when that will happen (and if it gets traction).

> I think this is perhaps the crux of the matter.  I do
> not believe that every old specification should be
> advanced along the standards track simply because it
> has been around a while and has multiple implementations.

+1 for the second statement.  The crux of the matter from
my POV is elsewhere, CRAM-MD5 is the best existing ESMTPA
mechanism in "real" MSAs I'm aware of.  For a definition
of "best" by "sending passwords in the clear isn't state
of the art".

> Advancing a specification to Draft Standard sends the
> signal that the IETF thinks the specification is a good
> idea and that people should deploy it.

IMHO that's why CRAM-MD5 as DS would be good, maybe some
implementors would care to read the second statement in
its security considerations.  

You could add some MUSTard about this in a 2195bis draft.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 04:49:11 +0200

Christian Huitema wrote:

> both Steve Bellovin and I presented the issues with such
> techniques.

Is that presentation online available somewhere ?  I find the
way to http://www3.ietf.org/proceedings/05aug/index.html but
then I'm lost.

> Basic challenge response mechanisms like CRAM-MD5 are simply
> too weak to be used on the Internet.  They are subject to
> dictionary attacks, which can retrieve the password in a very
> short time.

For a password in the dictionary, and if somebody sees the
challenge and the response.  With a somewhat unusual password
I wouldn't know how an attack works.

That's my real problem:  If users or worse implementors don't
know how stuff works it's bad.  What you end up with are some
hypothetical situations like this:

- a lottery with a cute crypto random algorithm, and everybody
  thought that it's perfect.  Turns out that it's useless if
  the list of participants is published together with the
  result of the lottery.
- a nice library where implementors use it as documented.  A
  few years later the IETF changes an obscure default in the
  library, and again years later an IETF WG decides that the
  implementations using the updated library are non-conforming
- an IETF ticket system where apparently nobody (and certainly
  not me) knows precisely why it used to work with my browser
  until summer 2005, but doesn't anymore
- ditto a famous bookshop where I ordered books securely for
  years, and now I use their insecure interface, because the
  former doesn't work anymore for me (only their server for
  the secure icons, but bad enough to be unusable for orders)
- a browser test site by a CERT where nobody knows why their
  test suite doesn't work with my browser (other test sites
  find no problem).
- an IETF server where my browser tells me again and again that
  the server certificate expired 1998 (the correct behaviour
  for this situation as far as I can judge it), but I'm pretty
  sure that it did work before

The good thing with CRAM-MD5 is that I know how it works, and
that I have at least some ideas about its limitations.  

I'm not really interested to negotiate charsets (especially not
if it boils down to "do you want UTF-8 or give up?"), security
layers (for a mail submission), or hash algorithms (by picking
CRAM-MD5 that point is moot).

Frank

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 07 Sep 2006 23:26:55 -0400

> hypothetical situations like this:

A hypothetical situation is one that could occur, but didn't.  A thinly 
veiled description of an actual situation is not a hypothetical.

>   the list of participants is published together with the

The spec was already quite clear on this.

>   implementations using the updated library are non-conforming

The change you are referring to in GSS-API v2u1 (RFC2743) is hardly to an 
"obscure default"; in fact, it was the addition of a new capability.  The 
API (_not_ the wire protocol) did change in a backward-incompatible way, 
and the spec documented that.  All that was required was to read the new 
API specification before using a library which implements the new version 
of the API.(*)

The SASL WG, which is not responsible for GSS-API, has not _decided_ that 
implementations of an old protocol using a newer library without updating 
to the new API are "non-conforming"; however, some of its individual 
members did point out that updating an implementation in this way can 
result in behavior that does not conform to that required by the original 
spec.  What the SASL WG _did_ decide was that its updated specification, 
retargeted against the new GSS-API version, needed to express a requirement 
made necessary by the backward-incompatible change.

>   test suite doesn't work with my browser (other test sites

I don't think I can help you with any of these.

>   sure that it did work before

Maybe your browser was broken before?
Maybe the cert wasn't expired before?
In any case, I don't think this scenario supports your argument that 
documenting a protocol is better than not documenting it, because I doubt 
that the problem is the result of an ill-defined or underspecified 
protocol.  Instead, I'd guess that it is a result of an oversight on the 
part of the operator of that server, combined with a complete lack of 
anyone bothering to report the problem (but that's just a guess, based on 
my experiences with people not bothering to report problems to me and then 
complaining that they never got fixed).

In addition, while I mostly agree that documenting a protocol is usually 
better than not documenting it, I fail to see the relevance of that point 
in this discussion.  If we're talking about what happened to newtrk or what 
the standards process should be, then we're talking about how to designate 
and advance protocol specifications that _are_ being published.

If we're talking specifically about CRAM-MD5, then please bear in mind that 
the SASL WG decided some time ago that the correct course of action was to 
produce an informational document describing CRAM-MD5 as deployed, rather 
than to produce an incompatible updated protocol which we would not ever 
encourage anyone to actually deploy.  For those watching from the 
sidelines, the updated document is draft-ietf-sasl-crammd5-07.txt.

-- Jeff

---

From: Christian Huitema <[email-masked]>
Date: Thu, 7 Sep 2006 21:22:37 -0700

> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Thursday, September 07, 2006 7:49 PM
> To: [email-masked]
> Subject: Re: RFC 2195 (Was: what happened to newtrk?)
> 
> Christian Huitema wrote:
> 

http://www.huitema.net/talks/ietf63-security.ppt

> I wouldn't know how an attack works.

You would not, but the gentle folks writing the cracking tool certainly
know. From the slide deck:

- If (the password) is generated by the user, it can certainly be
cracked
- If (the password) can be remembered by the user, it can probably be
cracked

Basically, host should only accept password challenges on secure
channels & after properly identifying the server posing the challenge.
CRAM-5 fails both tests. The channel is not encrypted, and the server
can be easily spoof, e.g. in a rogue Wi-Fi hot spot.

Note that this is not related to potential weaknesses in MD5. The
dictionary attack works just fine with other hash functions.

-- Christian Huitema

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 07:46:06 +0200

Jeffrey Hutzelman wrote:

> A thinly veiled description of an actual situation is not a
> hypothetical.

Okay, pick a better adjective, I tried to make the point that
there is a pattern in these real examples:  A technology where
only experts know how it works, while users get the choice OK
or CANCEL.

> The spec was already quite clear on this.

Yes.  Some wrote that the bug was to press the reset button,
others proposed to use another order of the list, but actually
it was a race condition, a communication problem between some
participants.  "Did you sell a certificate to [insert bank or
celebrity] ?" - "Yes" - oops.

> The change you are referring to in GSS-API v2u1 (RFC2743) is
> hardly to an "obscure default"

I'm only a lurker on the SASL list, and from my POV it was an
obscure issue.  The implementor tried to get it right, and used
the library as is, updating it when updates where available.  I
can understand that he's upset about this issue, he took that
updated library in good faith, checking the relevant RFCs.  Not
"your" (collective) fault, but a part of the pattern, even the
implementors are lost if the complete system is too complex.

Sometimes it has a funny side, I liked the "road to nowhere":
<http://www.proper.com/lookit/hash-futures-panel-notes.html>

 [other examples]
> I don't think I can help you with any of these.

That's what the CERT folks told me, I should install OpenSSL
and figure it out for myself... ;-)  Download and install was
fair enough, but admittedly I didn't manage to read the online
manuals so far.

 [expired cert]
> Maybe the cert wasn't expired before?

It wasn't (2005).  I'd have to check if it is only one the
known bugs in this browser (several running instances, only
one of them can lock the cert.db, all others get defaults)

> I don't think this scenario supports your argument that
> documenting a protocol is better than not documenting it,
> because I doubt that the problem is the result of an
> ill-defined or underspecified protocol.

My point was something in the direction of "don't replace
KISS by TLS unless you must".  2195 is fine for its purpose,
nobody proposed to use it as the new ideal way to transmit
credit card numbers.

> I'd guess that it is a result of an oversight on the part
> of the operator of that server, combined with a complete
> lack of anyone bothering to report the problem

Possible.  And you guessed correctly that I never tried to
nail that last issue.  For the ticket system I've given up
to report it, the complete issue is too ridiculous, one user
ietf password ietf can't get read access anymore, nobody
knows why, film@11.

> If we're talking about what happened to newtrk or what
> the standards process should be, then we're talking about
> how to designate and advance protocol specifications that
> _are_ being published.

RFC 2195 was mainly an example, I had to pick something that
I had actually implemented.  For the draft I can't claim this,
I haven't implemented SASLprep (maybe I'll try this later, the
part "yes, this is NFKC Unicode 5.0, but not 3.2" could be
interesting).

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 09:15:12 +0200

> http://www.huitema.net/talks/ietf63-security.ppt

Thanks, with that hint I finally found the HTML version:
http://www3.ietf.org/proceedings/05aug/slides/apparea-4/ and
http://www3.ietf.org/proceedings/05aug/slides/plenaryt-1.pdf

>> With a somewhat unusual password I wouldn't know how an
>> attack works.

> You would not, but the gentle folks writing the cracking tool
> certainly know.

Certainly I don't know where to rent the zombie for 10 cents:
http://www3.ietf.org/proceedings/05aug/slides/apparea-4/sld5.htm

Next slide, yes, CRAM-MD5 is *not* designed for that attack.
Adding a prose version of your slides 3..6 and 13 to the
security considerations of a 2195bis could improve it.  Do I
miss a clue, or has DIGEST-MD5 essentially the same issue ?

> Note that this is not related to potential weaknesses in MD5.

Right, add 20% to your costs to get SHA-1, etc.  How did you
calculate this, how long have the rented bots to crack a given
observed C/R ?

Frank

---

From: John C Klensin <[email-masked]>
Date: Fri, 08 Sep 2006 14:00:23 -0400

--On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman
<[email-masked]> wrote:

>     John> Actually, that topic opens up one of the fundamental
> issues     John> with our standards process ... one where
> better definition     John> and clear community consensus is,
> IMO, needed.  Measured by     John> our documented criteria,
> 2195 exists in multiple independent     John> implementations,
> has been widely deployed, and is considered     John> useful
> by many of those who are using it.  Current thinking     John>
> in the security area is that it isn't much better than the
> John> use of clear-text passwords, but our formal definitions
> of     John> the requirements for Draft Standard don't require
> that we     John> recommend the use of the protocol involved:
> "Draft" and "Not     John> Recommended" are perfectly
> consistent.
> 
> John, in principle I agree with you, but I'll point out there
> is a huge lack of clarity around ASes.  It's hard for example
> to find ASes for a given TS, and it would confuse people if
> something were a draft standard and not recommended at the
> same time.  This is particularly true given factors such as
> the rfc-index only lists the position along the standards
> track, not the requirements level of the associated AS.

At the risk of singing an old song again: (1) If the IESG (or
anyone else) doesn't believe that ASs are the solution to any
problem we have, then let's see a proposal to either make them
into such a solution or get rid of them.  (2) Newtrk tried to
address this particular issue, with ISDs as a product.  The IESG
didn't like it, nor were there any real suggestions about how
the issues the IESG saw could be resolved (or what resolutions
would meet the IESG's expectations/desires).  Perhaps I should
not infer from that that the IESG didn't see a problem worth
solving, but...  (3) If the IESG and IAB don't like the contents
of the rfc-index, it is my believe that it has always been
within their authority to negotiate different formats and/or
contents with the RFC Editor and that the RFC Editor has
generally been responsive to such requests. I note that, if
there was any attempt to get a new format, or requirements to
comply with a prospective new format design effort, into the RFC
Editor RFP, it somehow seems to have missed me.

> I would be all for draft but not recommended if we got to a
> point where the users of our documents would understand what
> that meant.

Your belief that they do not (I'd suggest that there is little
evidence that most users of our documents understand the real
difference between Proposed and Draft either) is not, I believe,
justification for nullifying the provisions of RFC 2026 and,
instead, substituting your (or the IESG's) judgment for them.

> I'm all for experiments--even ISD-like
> experiments--in organizing our metadata and descriptions of
> standards so people could get these points.  I don't have time
> to work on those experiments myself and so until they succeed
> my preference is to be conservative.

Our interpretation of "conservative" differs a bit in this case.
Given the identified problems with reliance on clear-text
challenge-response techniques, my version of "conservative"
would involve publishing a document that recognizes the wide
deployment and use of protocols of this sort but that carefully
explains (perhaps partially by reference, rather than inclusion
of everything in-line) the risks and limitations associated with
relying on them in unprotected environments.   If one does not
believe in recommendation levels, then it becomes an interesting
question about what maturity level should be assigned to such a
document, but I do not believe we have a model for Informational
documents superceding ("Obsoletes") a standards-track document.

>     John> It is not consistent with our published policies as
> I read     John> them to refuse to promote it to Draft simply
> because there     John> is general feeling that security
> technology has passed it     John> by.  But that is, I think,
> exactly what would happen today     John> if the protocol were
> judgment of the technical quality of a protocol (and the TS)
> when advancing along the standards track.  I'd always assumed
> that the IESG should include factors like security in that
> determination--not just interoperability.  Heck, I even
> assumed it was reasonable to have a higher bar for spec
> clarity at DS than PS.

I think both of those (spec quality and factors like security)
are useful and important.  But 2026 seems very clear on this
subject:

> 4.1.2  Draft Standard
> 
>    A specification from which at least two independent and
>    interoperable implementations from different code bases
>    have been developed, and for which sufficient successful
>    operational experience has been obtained, may be elevated
>    to the "Draft Standard" level.  For the purposes of this
>    section, "interoperable" means to be functionally
>    equivalent or interchangeable components of the system or
>    process in which they are used.  
>    [...] Elevation to
>    Draft Standard is a major advance in status, indicating a
>    strong belief that the specification is mature and will be
>    useful.

This specification is about as mature as it is going to get.  As
Frank has pointed out, the critical strings are actually
well-specified with regard to encoding, etc. and the others are
opaque and a server-only or client-only problem.  One can warn
against its use (and I think should do so), but the deployment
of the protocol gives all of the proof needed about utility.

Note that full Standards are different: the requirement there
(but only there) includes "provides significant benefit to the
Internet
community" and one could sensibly claim that a protocol,
especially one that was intended to enhance security, that posed
serious security risks if deployed carelessly does not, on
balance, provide such benefits.

I believe that, if there is a difference of opinion here, it is
that I believe that a widely-deployed, useful (in the opinions
of those who haFrom [email-masked] Fri Sep 08 14:21:26 2006
Date: Fri, 08 Sep 2006 14:00:23 -0400
From: John C Klensin <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: what happened to newtrk?

--On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman
<[email-masked]> wrote:

>     John> Actually, that topic opens up one of the fundamental
> issues     John> with our standards process ... one where
> better definition     John> and clear community consensus is,
> IMO, needed.  Measured by     John> our documented criteria,
> 2195 exists in multiple independent     John> implementations,
> has been widely deployed, and is considered     John> useful
> by many of those who are using it.  Current thinking     John>
> in the security area is that it isn't much better than the
> John> use of clear-text passwords, but our formal definitions
> of     John> the requirements for Draft Standard don't require
> that we     John> recommend the use of the protocol involved:
> "Draft" and "Not     John> Recommended" are perfectly
> consistent.
> 
> John, in principle I agree with you, but I'll point out there
> is a huge lack of clarity around ASes.  It's hard for example
> to find ASes for a given TS, and it would confuse people if
> something were a draft standard and not recommended at the
> same time.  This is particularly true given factors such as
> the rfc-index only lists the position along the standards
> track, not the requirements level of the associated AS.

At the risk of singing an old song again: (1) If the IESG (or
anyone else) doesn't believe that ASs are the solution to any
problem we have, then let's see a proposal to either make them
into such a solution or get rid of them.  (2) Newtrk tried to
address this particular issue, with ISDs as a product.  The IESG
didn't like it, nor were there any real suggestions about how
the issues the IESG saw could be resolved (or what resolutions
would meet the IESG's expectations/desires).  Perhaps I should
not infer from that that the IESG didn't see a problem worth
solving, but...  (3) If the IESG and IAB don't like the contents
of the rfc-index, it is my believe that it has always been
within their authority to negotiate different formats and/or
contents with the RFC Editor and that the RFC Editor has
generally been responsive deployed and used it) protocol for which
multiple independent implementations exist (and have been
deployed) should be documented and put/left on the standards
track as a specification of how things should be done if one
chooses to do those things.   I also believe that such a
document may reasonably contain any qualifying language -- and
even warnings and/or threats-- the community considers
appropriate and note that 2026 explicitly provides for AS
information to be folded into what would otherwise be a TS RFC.
So my view of what should be done with the standards-track RFCs
that are based on CRAM-MD5 is that the RFCs should be reissued,
with tightened definitions as needed, extensive security
considerations sections, and a strong recommendation to not use
the things except under specific and controlled circumstances.
If the documents meet the published requirements for Draft, then
they should be published at Draft.

The recent practice in the IESG appears to have been closer to
"if we don't like it or would not recommend it, it should not be
published at all, especially on the standards track no matter
how widely interoperable implementations are deployed".  I can
find little support for that position in RFC 2026 or elsewhere.
And, again, I don't recall hearing a proposal --to Newtrk or
elsewhere-- to change it.

    john

---

Date: Fri, 8 Sep 2006 11:09:37 -0700

I believe that, if there is a difference of opinion here, it is
that I believe that a widely-deployed, useful (in the opinions
of those who haxyzzy.claranet.de>
From: Christian Huitema <[email-masked]>
To: Frank Ellermann <[email-masked]>, <[email-masked]>
Cc: 
Subject: RE: RFC 2195 (Was: what happened to newtrk?)

> Next slide, yes, CRAM-MD5 is *not* designed for that attack.

That is my point. We should not, in 2006, standardize "security" methods
that are not robust against a fairly well known attack.

> miss a clue, or has DIGEST-MD5 essentially the same issue ?

DIGEST-MD5 is somewhat more robust than CRAM-MD5 because it incorporates
protection against "chosen plaintext" attacks. If an attacker can fake a
server and send a chosen challenge, then the dictionary attack can be
accelerated with a pre-computed catalog. However, current dictionary
attacks do not need to rely on pre-computation, since a modern PC can
compute more than a million MD5 hashes per second. So, yes, DIGEST-MD5
has essentially the same issue.

-- Christian Huitema

ve deployed and used it) protocol for which

    john

---

From: Christian Huitema <[email-masked]>
Date: Fri, 8 Sep 2006 11:09:37 -0700

-- Christian Huitema

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Sep 2006 20:55:22 +0200

Christian Huitema wrote:

> yes, DIGEST-MD5 has essentially the same issue.

If the SASL folks want their very own "decruft" experiment
they'd have to update RFCs 2244, 2645, 3013 (a BCP), check    
ESMTPA in 3848, do something about 2617, and probably some
more RFCs.

DIGEST-MD5 and OTP are registered as "common", not only
"limited" like CRAM-MD5.

Frank

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 8 Sep 2006 22:09:56 -0700 (PDT)

On Fri, 8 Sep 2006, John C Klensin wrote:
> --On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman wrote:
[ ... ]
> find little support for that position in RFC 2026 or elsewhere.

I think that Mr Hartman is right and that Mr Klensin is mistaken.

As I read it, section 6 of RFC 2026 not only gives the IESG the
latitude to make a judgment of the technical quality of a
specification when advancing it along the standards track, but
actually REQUIRES the IESG to do so:

|6.  THE INTERNET STANDARDS PROCESS
|
|   The mechanics of the Internet Standards Process involve decisions of
|   the IESG concerning the elevation of a specification onto the
|   standards track or the movement of a standards-track specification
|   from one maturity level to another.  Although a number of reasonably
|   objective criteria (described below and in section 4) are available
|   to guide the IESG in making a decision to move a specification onto,
|   along, or off the standards track, there is no algorithmic guarantee
|   of elevation to or progression along the standards track for any
|   specification.  The experienced collective judgment of the IESG
|   concerning the technical quality of a specification proposed for
|   elevation to or advancement in the standards track is an essential
|   component of the decision-making process.
...
|6.1.2  IESG Review and Approval
|
|   The IESG shall determine whether or not a specification submitted to
|   it according to section 6.1.1 satisfies the applicable criteria for
|   the recommended action (see sections 4.1 and 4.2), and shall in
|   addition determine whether or not the technical quality and clarity
|   of the specification is consistent with that expected for the
|   maturity level to which the specification is recommended.

//cmh

---

From: John C Klensin <[email-masked]>
Date: Sat, 09 Sep 2006 13:26:00 -0400

--On Friday, 08 September, 2006 22:09 -0700 "C. M. Heard"
<[email-masked]> wrote:

>> wrote:
>> > OK.  I read RFC 2026 as giving the IESG the latitude to
>> > make a judgment of the technical quality of a protocol (and
>> > the TS) when advancing along the standards track.  I'd
>> > always assumed that the IESG should include factors like
>> > security in that determination--not just interoperability.
>> > Heck, I even assumed it was reasonable to have a higher bar
>> > for spec clarity at DS than PS.
>> 
>> >    strong belief that the specification is mature and will
>> >    be useful.
> [ ... ]
>> If the documents meet the published requirements for Draft,
>> then they should be published at Draft.
>> 
>> "if we don't like it or would not recommend it, it should not
>> be published at all, especially on the standards track no
>> matter how widely interoperable implementations are
>> deployed".  I can find little support for that position in
>> RFC 2026 or elsewhere.
> 

I don't think this is even a question of right or wrong
(mistaken), but of interpretation and appropriateness.   There
are also some issues about when the exercise of judgment and
discretion turns into either abuse of process or substituting
IESG judgment for the judgment or the community or that of the
marketplace.    I am also trying to suggest that, where these
sections of 2026 to be reopened, there might be pressures to
narrow IESG authority in addition to those for broadening it,
and for reasons exactly connected to those issues about the
appropriate range of discretion.

I note that, in the middle of the "decruft" process, at least
two proposals were introduced (one less formally than the other)
to require giving more weight to marketplace decisions, rather
than IESG judgment, in determining which specifications were
advanced.  Those proposals were not debated and rejected by the
community.  Instead, they simply disappeared after it became
clear that the IESG would not be receptive to any reduction of
the authority of their opinions.  That may have been the right
decision, but the community never had a chance to make it.

> |   The mechanics of the Internet Standards Process involve
> decisions of |   the IESG concerning the elevation of a
> specification onto the |   standards track or the movement of
> a standards-track specification |   from one maturity level to
> another.  Although a number of reasonably |   objective
> criteria (described below and in section 4) are available |
> to guide the IESG in making a decision to move a specification
> onto, |   along, or off the standards track, there is no
> algorithmic guarantee |   of elevation to or progression along
> the standards track for any |   specification.  The
> experienced collective judgment of the IESG |   concerning the
> technical quality of a specification proposed for |
> elevation to or advancement in the standards track is an
> essential |   component of the decision-making process.
> ...

>From my point of view, we have two issues here.  The first is
that I see the IESG as the interpreter of community consensus
rather than as an authority in itself.  This text sounds
remarkably like "self-sufficient authority".  I don't believe
that was the community's intent when 2026 was written.  More
important, as time goes on and the composition of the IESG and
the community of active IETF participants shifts, I think it has
become less appropriate.

The second is a meta-issue about what the above means by
"technical quality".  Certainly the clarity of the specification
is a key issue (and is is, as you point out, called out in
6.1.2).  But our traditional tool for both evaluating and
refining document quality is independent interoperable
implementations.  While documents can always be improved, if
such implementations were created without difficulties, that
should create a strong presumption that the document is clear
enough.  

Of course, there are other issues in technical quality.  A
protocol that simply won't do the job claimed for it should have
either the protocol or the claim adjusted before publication.  A
protocol that might be harmful to the Internet generally should
either be rejected or published with appropriate explanation,
warnings, and disclaimers.

Where I'm probably out near the fringe of the IETF community is
that, after more than three decades of involvement in
standardization efforts of several types, I've gotten very
skeptical of the impact of a standards-producing body approving
some things and not others on the basis of how they feel about
them.  I am very much in favor of high specification quality.  I
am also in favor of avoiding putting the label "standard" on
something until after it is proven to be implementable and
feasible.   But, ultimately, the marketplace will do what it
does and the primary contribution of a standardization effort is
not to approve or disapprove, but to increase the odds that, (i)
if two implementers or organizations want to do the same thing,
they have the opportunity to do it in a compatible and
interoperable way and (ii) if a procuring organization doesn't
want to be limited to a single source, they have a better
opportunity to specify what they are looking for in a way that
will encourage competition.

>From that point of view, we should aspire to specifications that
are absolutely clear about their strengths and weaknesses
_especially_ where security and basic network operations (e.g.,
scalability) are concerned.  But, once those specifications are
clear enough (for a given level), I think we should publish
them, ideally with indications of both maturity and how much we
think they are good ideas.  I expect that the marketplace will
take "maturity" more seriously than recommendation levels, but
that is another issue.  And, if the marketplace responds by
implementing and deploying something widely, even if the IESG
thinks it is a terrible idea, I think we have some level of
obligation to improve the specification (including better
explanations about what it terrible about it if those are
appropriate), and publish the result... on the standards track
in order to continue to facilitate interoperability.

     john

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 10 Sep 2006 20:58:43 +0200

John C Klensin wrote:

 [skipping many good points]
> I am very much in favor of high specification quality.
[...]
> we should aspire to specifications that are absolutely clear
> about their strengths and weaknesses _especially_ where
> security and basic network operations (e.g., scalability) are
> concerned.

Yes, e.g. STD 61 (2289, OTP) is ready in some way, and somebody
cared to submit an implementation report.  For the new SASL I've
not heard that anybody intends to SASLprep 2444.  Whatever that
means, if used instead of CRAM-MD5 it wouldn't be _that_ much
better wrt the dictionary attack discussed here before.

For a CRAM-MD5 "AS" it boils down to "if all you want is not
sending passwords in the clear you could ... BUT ...".   One
detail I like about OTP and CRAM-MD5 is that they need only 3
parameters where 2831 takes 9 or 10.

A future 2026bis could make it clearer that anybody may submit
an implementation / interoperability report, not only the
original authors / editors.  BTW, RFC 4234 to STD, anybody ?

And of course RFC 4409 to STD, there I'd prefer to explicitly
mention the Resent-* case in its section 8.1, and that would
need a minor editorial update (+ a new informative reference).
And if anybody insists on it add a caveat about CRAM-MD5 etc.

Frank

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 Sep 2006 14:50:50 -0400

Eliot,

The discussion of the question you asked here seems to have been 
immediately sidetracked.  I, at least, believe the original 
question is worth some community discussion and possibly a 
conclusion.  More below.

--On Tuesday, September 05, 2006 4:39 PM +0200 Eliot Lear 
<[email-masked]> wrote:

> All,
>
> As a participant in the newtrk working group and someone who
> actually ran one of the only reasonably successful experiments
> in that group, I think the community is owed a better
> accounting of why WG failed, and that steps should be taken to
> see that such efforts do not fail in the future.  The newtrk
> working group was chartered to revise the standards track,
> with an understanding that the current one is demonstrably not
> working as it should.
>...
>  However, the end result was that we had a working
> group chartered to do a specific task, do the task, and then
> have the work rejected.  Quite frankly we don't have the
> resources to have that happen.  I suspect anyone who had any
> involvement with that group will be extremely reticent to work
> on process proposals in the future, because they will assume
> that any given IESG is likely to reject any output.

That is certainly the conclusion to which I, and at least some 
others who put energy into Newtrk and related work, have come.

> prevent this from happening.  Was the newtrk charter not
> sufficiently narrow to accomplish a task for which there was
> community consensus?  Is a working group the appropriate place
> to make process changes?  I am leaning heavily toward "no" on
> that last one.  Should the IESG simply both propose and
> dispose?  Perhaps the IAB has a role of proposing changes.

I do not believe that WG-or-not is the key issue, even though I 
continue to have doubts as to whether a regular WG is adequately 
representative of the IETF participants impacted by significant 
process changes to be the ideal final review mechanism.   Within 
limits, a WG may be a reasonable mechanism for proposing 
approaches and solutions and/or working through details of them, 
but we do need to be careful about creating WGs that are 
dominated by would-be process experts with little actual 
experience in the technical work of the IETF.

> Eventually, as I wrote in a previous note, we must circle back
> and actually fix the standards process to reflect reality.
> But how that is to be done remains to me an open question.

I think the lesson to be drawn is that one that you have implied 
above: it is unlikely that any serious process changes will 
succeed as long as the IESG is the body that must approve such 
changes.  This is not a criticism of any particular IESG or IESG 
member.  Instead, it is the result of observation and 
experience: the IESG is appointed to do a particular job, is 
under huge pressures to do that job, and tends to "train" new 
members about how that job works.  Any new model of the job to 
be done naturally leads to a very conservative reaction: doing 
things differently will always involve more work, if only in 
developing new detailed procedures and non-disruptive transition 
mechanisms, and we tend (properly) to select IESG members whose 
primary commitment is to the short-term objective of processing 
as much of the IETF's technical work as possible.

The consequence is that it is unreasonable to expect the IESG to 
evaluate and agree to non-trivial process changes.  Even if I 
had not been convinced of that after the Newtrk meltdown, the 
recent response to draft-klensin-norm-ref would have been 
completely persuasive.  That response isn't wrong -- both the 
model in RFC 3933 and the I-D were written to give the IESG the 
discretion to reach the conclusion they reached -- but it shows 
a response so conservative as to make the writing of the 
proposal not worth the effort, at least IMO.

That, I think, leaves two questions for the community:

(1) How should things be arranged so that the IESG does not make 
the final decisions about process changes?   And,

(2) If the community can reach some rough consensus on the 
answer to that question, how does one get the IESG --which has 
not been sympathetic to efforts to reduce their perceived 
authority-- to approve it or how does it get adopted without 
IESG approval.

I am not yet to the point that I would try to get the community 
to convince the Nomcom that a promise to approve a proposal to 
transfer approval of process changes away from the IESG should 
be a precondition for appointment (or reappointment) to the IESG 
but, if the community is serious about process changes, it could 
come to that.

Just my opinion

    john

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Sep 2006 22:24:50 +0200

John C Klensin wrote:
> immediately sidetracked.  I, at least, believe the original question
> is worth some community discussion and possibly a conclusion.  More
> below.

Thank you, John.  You've caught the jist of my concerns quite well.  I
am a bit reticent at this point to propose changes.  I think we have a
problem.  Mike Heard  had a reasonable point of view as well, which is
that perhaps the newtrk charter wasn't quite as constrained as it needed
to be for this kind of change.  I do think at this point and time we are
not making the best use of the IAB, but again, I don't know what changes
I would propose to effect change.  I do wish we could have a broader
discussion.

Eliot

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 12 Sep 2006 16:32:03 -0400

> I would propose to effect change.  I do wish we could have a broader
The IAB spends -- or spent; I haven't been on the IAB since 2000 -- an
amazing percentage of its time on layer 9 issues. Most IAB members dislike
that (and some ignore that part), but much of it seemed to be stuff that
the IETF had to do.  I suppose we could ask the Nomcom to select an IPB or
an IPSG as well, but all things considered (and as one of the former
stuckees) I think we're better off if our political relations were handled
by folks with technical clue -- that is why the IETF's participation is
generally sought.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Sep 2006 09:29:53 +0200

Steve,
> by folks with technical clue -- that is why the IETF's participation is

I agree, and while I don't really know what can be done around the
external layer 9 issues, I don't think we have the balance quite right
between the IAB and the IESG.  The problem is that I also don't fully
understand how the law of unintended consequences would play out if we
tinkered.  So for instance, suppose we had a rule that said that
standards process changes were to be approved ONLY by the IAB?  Could
such a rule be used to bypass the IESG by an individual who didn't like
a decision made by that body?  And who gets to arbitrate over what a
process change is?  What about IANA considerations, for instance?  This
is NOT to say that using the IAB is the only avenue.  Perhaps the right
approach is simply NOT to have WGs make these proposals but instead let
them flow from individuals sponsored either by an IESG or IAB member.

Why am I thinking along these lines?  It's simply because I believe we
have ossified too much, and when the WG acted as intended, the IESG did
not properly respond (IMHO).  And again, I really don't know what sort
of proposal would be best (if any).

Eliot