--On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu> wrote:
"John" == John C Klensin <john-ietf(_at_)jck(_dot_)com> 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.
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
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.
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 have 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf