On Friday, September 08, 2006 04:49:11 AM +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
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 hypothetical situation is one that could occur, but didn't. A thinly
veiled description of an actual situation is not a hypothetical.
- 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.
The spec was already quite clear on this.
- 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
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.
- 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).
I don't think I can help you with any of these.
- 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
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf