ietf-nntp LIST EXTENSION caching, latest wording

[Clive D.W. Feather]

Okay, here's what I've produced following the flurry of messages over the
weekend.

Personally, I still think it's better to have this stuff in there than
nothing at all, but I agree it's important to send the right messages
on security. So I hope we can all feel we're converging on good text.

In 5.3.2, one paragraph:

   While some extensions are likely to be always available or never
   available, others will "appear" and "disappear" depending on other
   changes. An NNTP client may cache the results of this command, but
   MUST NOT rely on any cached results - whether from earlier in this
   session or from a previous session - remaining correct, MUST cope
   gracefully with the cached status being out of date, and SHOULD (if
   caching results) provide a way to force the cached information to be
   refreshed. Furthermore, a client MUST NOT use cached results in
   relation to security, privacy, and authentication extensions. See
   Section 11.6 for further discussion of this topic.

11.6 Caching of LIST EXTENSIONS results

   The LIST EXTENSIONS command provides information about the extensions
   currently available from the server. Whenever there is a relevant
   change to the server state, the results of this command are required
   to change accordingly.

   In most situations the results from this command in a given server
   state will not change from session to session; a given extension will
   be installed permanently on a server. Some clients may therefore wish
   to remember which extensions a server supports to avoid the delay of
   an additional command and response, particularly if they open
   multiple connections in the same session.

   However, information about extensions related to security and privacy
   MUST NOT be cached, since this could allow a variety of attacks.

   For example, consider a server which permits the use of cleartext
   passwords on links that are encrypted but not otherwise:

      [Initial TCP connection setup completed.]
      [S] 200 NNTP Service Ready, posting permitted
      [C] LIST EXTENSIONS
      [S] 202 Extensions supported:
      [S] XENCRYPT
      [S] .
      [C] XENCRYPT
      [Client and server negotiate encryption on the link]
      [S] 283 Encrypted link established
      [C] LIST EXTENSIONS
      [S] 202 Extensions supported:
      [S] XSECRET
      [S] .
      [C] XSECRET   fred flintstone
      [S] 290 Password for fred accepted

   If the client caches the last LIST EXTENSIONS result, then on the
   next session it will attempt to use XSECRET on an unencrypted link:

      [Initial TCP connection setup completed.]
      [S] 200 NNTP Service Ready, posting permitted
      [C] XSECRET   fred flintstone
      [S] 483 Only permitted on secure links

   exposing the password to any eavesdropper. While the primary cause of
   this is passing a secret without first checking the security of the
   link, caching of LIST EXTENSIONS results can increase the risk.

   Any security extension should include requirements to check the
   security state of the link in a manner appropriate to that extension.

   Caching should normally only be considered for anonymous clients that
   do not use any security or privacy extensions and for which the time
   required for an additional command and response is a noticable issue.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646