ietf-nntp LIST EXTENSIONS caching

[Charles Lindsey]

In <20031010100042.GA87131 at finch-staff-1.thus.net> "Clive D.W. Feather" <clive at demon.net> writes:

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

That "not rely" wording is too inconspicuous.

I would suggest starting a new paragraph at that "However". And I would
say that there are dangers in cacheing (just as there are with not using
LIST EXTENSIONS at all) and implementors need to be prepared for the cache
becoming out of date and MUST cope gracefully ... (e.g. by issuing LIST
EXTENSIONS again if harm could arise [cue discussion on security and
privacy]).

Note that I dislike using MUST-wording in security consideration (though it
may not be avoidable altogether). The Security Considerations section is
intended to warn implementors of Bad Things that can happen, and maybe
suggest how to avoid them. If MUST wording appears to be needed, that
suggests that the requirement in question should be in the protocol
sections of the document.

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


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

Actually, what you should be saying is that people who design security
extensions SHOULD include requirements to check the security state of the
link. I.e. those requirements belong in the definitions of those security
extensions and not here. Like I said, we identify a Bad Thing that could
happen, and _suggest_ a fix, namely that those who write such extensions
(we don't actually have any yet, though they are being discussed) SHOULD
take the problem on board.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5