W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: http-digest-aa-rev-00.txt

From: David Jablon <dpj@world.std.com>
Date: Wed, 06 Aug 1997 20:14:16 -0400
Message-Id: <3.0.1.16.19970806201416.0877b0ba@world.std.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
John,

I find it absurd to categorically preclude "any use of
public-key techniques" for password authentication in HTTP.
In light of the importance of HTTP, and the fact that
passwords are widely-used on the web, I question the
motivation behind "Digest Authentication".

Why limit HTTP password verification to a broken method?
If you're going to the trouble to change it, why not
do it right?

But at least your explanation was more revealing of intent
than the draft.  It is enlightening that the authors of
the draft would choose to be more restrictive than
the U.S. government, which has never limited export of
strong password authentication.

At 09:12 AM 8/6/97 -0500, John Franks wrote:
>To quote from the draft:
>
>   "Digest Authentication does not provide a strong authentication
>   mechanism.  That is not its intent.  It is intended solely to replace
>   a much weaker and even more dangerous authentication mechanism: Basic
>   Authentication.  An important design constraint is that the new
>   authentication scheme be free of patent and export restrictions."
>
>The necessity to avoid any patent and export restrictions is
>fundamental.  In particular, protocols which make any use of
>public-key techniques are not acceptable.

So again, I ask:

Why impose these restrictions?

The authors have failed to investigate whether freely
available or cheaply available strong alternatives exist,
so your excuse about "fundamental restrictions" just
doesn't cut it.

I can only presume that the vendors behind this proposal
would rather support a weak password method than a strong
one, in line with an unwritten agenda.

As I wrote:

>> Several password-based protocols are known that
>> are much better than the one described in this
>> document

To be specific, I can name EKE, SPEKE, "secret public-key"
techniques, OKE, SRP-2, and several others.  In the spirit of
honesty and openness, I'll do my part.  My motivation
is in part due to the fact that I'm the author of one
of these methods.

It is wrong for the authors of this document to dismiss
the entire class of strong techniques without adequate
explanation.  To do so without even acknowledging their
existence is a true public disservice.

-- David

------------------------------------
David Jablon
http://world.std.com/~dpj/
dpj@world.std.com
Received on Wednesday, 6 August 1997 17:13:49 EDT

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