W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: [Ietf-http-auth] Updating RFC 2617 (HTTP Digest) to use UTF-8

From: Ingo Struck <lists@ingostruck.de>
Date: Sun, 15 Oct 2006 18:30:08 +0000
To: Adam Roach <adam@nostrum.com>
Cc: lists@ingostruck.de, Robert Sayre <sayrer@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <200610151830.11306.lists@ingostruck.de>

Adam, Robert,

> > - some netscape descendants tend to use a stale nonce
> >   after the server sent an updated nonce
>
> As I've pointed out many times over the past several years: 2617
> contains _conflicting_ language regarding whether H(A1) should be
> recalculated upon receipt of nextnonce when using MD5-sess. It would
> take one short sentence to resolve this ambiguity one way or the other.
I agree that a clarification would help, but I do not agree
that the rfc really is ambiguous (see my mail from 2006-08-09
to the wg list).
Anyway, the brokenness of the implementations I pointed out
have nothing to do with issuing a nextnonce.
The clients re-calculate the session-id for *every* request,
even with a pertained nonce (but with a different cnonce), 
which is (unambiguously) a violation of the spec.

The "stale nonce" problem mentioned does not only affect MD5-sess
but simple MD5 too. Some browser implementations seem to use broken
multi-threading in combination with concurrent connections to the
same server such that one thread sends a stale nonce (within MD5 algo!)
after a previous response from the server already marked that nonce
as stale. It seems that access to "session-data" within those
browsers is not synchronised among different i/o-threads.

> > Bottom-line of the tests performed is, that nearly any
> > known rfc2617 client-side implementation is more or less
> > broken
>
> That is the main metric the IETF uses when deciding whether to drop a
> capability. Also, there is no reason to include MD5-sess in the same
> document.
Using such a metric would mean to drop usage of rfc 2616 / 2617
completely (nearly any implementation out there is "broken" in
the sense of complying to the rfc in some way or other. 
Especially the implementations of the prevalently used browsers
out there are an utter mess -- I guess I do not have to specify
the details here).

I would agree that it could be a good idea, though, to move
the specification of the algorithms used by rfc2617 out to
separate standards tracks.

Kind regards

Ingo Struck
Received on Sunday, 15 October 2006 17:27:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:49:53 GMT