- 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
> > 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 UTC