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

Larry, Phillip, Paul, John, and other authors of the draft,

I apologize for raising an old issue with the WG,
and for implying that the work behind this was not
well considered.  I just looked at the draft as a
standalone document, and did not find clear support
or explanation for the resulting design.

The combined responses of John, Paul, Phillip, and Larry
provide a much clearer reason for the design decisions,
however I might disagree with the outcome.
My concern comes from the fact that the rationale
for restriction to this method is not captured in
the draft.

So, without further insult, or re-hashing of old issues,
I'd suggest that the draft be amended slightly to
include more of the careful considerations of the
authors.  (specific suggestions at end)


Frank wrote:
>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.

In questioning this rationale (in obviously a
too-nasty way) I stimulated the following responses:

Paul wrote:
>1. Digest Auth standardization was started a fair while ago, and even
>then its intent was to standardize an existing practice. Many
>potentially interesting changes were shot down because they weren't
>backwards compatible.

This should be captured in the draft.  It definitely makes
the work sound more diligent.

Paul:
>2. The statements in the draft about weakness were made primarily to
>appease certain parties who would not agree that any shared secret
>authentication mechanism deserved to be called "strong", due to the
>difficulty of distributing the secrets.

I think including accurate factual statements of weakness is very
important.  Opinions on proper forms of certification and
key distribution tend to be a little more controversial, and
I'd avoid using "strong" and "weak" in this regard in such
documents.

Paul:
>3. I, at least, believe there is a place for shared secret based
>authentication. Many sites in the web to not use authentication on
>anything except credit card pyment pages because Basic is stupid, and
>SSL slows down there sites by orders of magnitude. Thus, we were
>explicitlu after a shared secret mechanism, and hence, for the purpose
>for which Digest was intended, it was not our responsibility to explore
>public key alternatives.

... and Phillip:
>I can assure David that those involved have a great deal of knowledge of 
>and expertise in the use of public key encryption techniques. Even if there
>were absolutely no patent restrictions I would still want to have a shared
>secret scheme available. Without special hardware a public key operation
>takes several hundred milliseconds on comparatively upscale hardware
>platforms. It is simply not acceptable that the only secure authentication
>mechanism restrict such servers to one or two hits per second.

The speed requirement should be in the draft.

Paul:
>4. At the time we were writing the spec, we knew of no public key based
>mechanism that was appropriately unencumbered by patent restrictions,
>and in all the time the spec has been out, no one until now has
>suggested one to us.
>To simply blatantly claim we were derelict in our duty is boorish.

Ok.  Sorry I implied you guys were neglectful, and I hope
you'll not hold my rudeness against me.  I probably wouldn't
have said what I said if the draft contained a full rationale.
It seems important to capture careful reasoning in
print to insure that future readers also don't jump to
conclusions.

Larry wrote:
> If you wish to suggest some editorial change to the wording of the
> draft that goes beyond what is already there, then please make some
> specific suggestions; however, check your conspiracy theories at the
> door.

Ok.  But "conspiracy theories"?  My statement was simply that
the draft had a "hidden agenda", which is true, for readers
who didn't follow the working group from the start.  Frank, Paul,
and Philip have made the agenda clear in their responses.
I think the draft should incorporate their points.

Specific suggestions
--------------------
The method was chosen for a variety of reasons, as discussed
in the draft, but the discussion should also include at least
one paragraph that incorporates the following reasons
(restated appropriately by the authors):

1) to be compatibile with and standardize on existing practice.

2) because implementations of public-key based methods
	were found to be too slow.

3) because no unpatented public-key alternatives were known
	to the authors, and

4) because patent licensing was out of the question,
	because of (...)

5) to avoid export regulations (specifically ...)

Also, there is discussion about brute-force attack on the
encrypted password database, but a potentially larger
threat is an eavesdropper performing a brute-force attack
on the challenge and response messages.  The document
should describe this weakness too.

Thanks.

------------------------------------
David Jablon
http://world.std.com/~dpj/
dpj@world.std.com

Received on Thursday, 7 August 1997 09:50:32 UTC