W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Where should Digest go next?

From: Ned Freed <NED@innosoft.com>
Date: Wed, 03 Jan 1996 19:32:23 -0800 (PST)
To: "Donald E. Eastlake 3rd" <dee@cybercash.com>
Cc: Larry Masinter <masinter@parc.xerox.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01HZL313TDBO9AMJDE@INNOSOFT.COM>
> > I'm just trying to figure out how to deal with 'Digest Authentication'
> > in the face of claims that the mechanism has well known holes and
> > limitations. Here are the procedural options, as far as I can see
> > them:

> > 1- Submit as Proposed standard as part of HTTP/1.1
> > 2- Submit as Proposed standard as a separate document
> > 3- Submit as Informational, as part of HTTP/1.0
> > 4- Submit as Informational, as a separate document
> > 5- Don't handle as part of IETF

> > The problem with options 1 and 2 is whether such Proposed Standards
> > would have a chance of actually making it to Standard without change.
> > I don't think this will work out: the standards track really does
> > require us to propose solutions that don't have major holes, and if
> > we're not interested in fixing the known problems, trying to move
> > along standards track is inappropriate.

> I can't see anything wrong with having a spectrum of solutions that
> meet a spectrum of threat environments.  Security need not be
> perfect to be useful.

I have to agree with Donald on this. The IETF always seems to want to hold out
for some general, universally applicable, and perfect security scheme. Nothing
else will do. And meanwhile we never seem to get any useful security
standardized, or when we do it takes much too long to get it through the
process.

The requirements imposed by the process do not say we cannot have multiple
schemes with different realms of applicability. There is also no reason why we
cannot move this forward now but push it off to historic if it doesn't pan out.

The question that needs to be asked is whether or not this scheme is really
useful in it's own right, not whether or not we'll be able in the fullness of
time to do better. If it really is useful it should be standardized even if
other approaches are standardized as well. If it isn't useful it should
probably still be published, but it should be relegated to some category where
implementation is not recommended or encouraged.

				Ned
Received on Wednesday, 3 January 1996 19:47:42 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:42 EDT