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