ietf-nntp LIST EXTENSIONS caching

[Clive D.W. Feather]

Okay, here's the text I now have. Can people please comment on it? I
will change the SHOULDs to MUSTs iff Russ tells me to.

[In 5.3.2]

   An NNTP client MUST NOT rely on any cached results from this command,
   either earlier in this session or in a previous session, remaining
   correct. While some extensions are likely to be always available or
   never available, others will "appear" and "disappear" depending on
   other changes. Furthermore, a server SHOULD NOT use cached results in
   relation to security, privacy, and authentication extensions. See
   Section 11.6 for further discussion of this topic.

[and then]

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. Therefore, once it has
   established a working state - for example, by using MODE READER or
   setting up an encrypted connection to the server - it is reasonable
   for a client to cache extension status between sessions and use this
   cached information when deciding whether or not to use a particular
   extension, rather than using the LIST EXTENSIONS command in every
   session. However, such implementations MUST NOT rely on any cached
   results from this command remaining correct, MUST cope gracefully
   with the cached status being out of date, and SHOULD provide a way to
   force the cached information to be refreshed.

   However, there are risks in caching information about extensions
   related to security and privacy.

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

      [C] LIST EXTENSIONS
      [S] 202 Extensions supported:
      [S] ENCRYPT
      [S] .
      [C] ENCRYPT
      [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:

      [C] XSECRET   fred flintstone
      [S] 483 Only permitted on secure links

   exposing the password to any eavesdropper.

   Therefore a client sending private information, such as a cleartext
   password, to a server SHOULD check the security state of the link and
   the identity of the server immediately beforehand and SHOULD NOT rely
   on the (cached) results of any previous check. How such a check is
   done will, of course, depend on the particular facilities available
   from the server.

   An even better approach, though, is to use authentication mechanisms
   that work on an insecure link (e.g. public-key signatures).

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