ietf-nntp Draft 20 pre-release 2

[Clive D.W. Feather]

Russ Allbery said:
> I don't.  I agree with all of those statements.  I also think that caching
> of LIST EXTENSIONS for such things as SASL mechanisms is a MUST NOT per
> the SASL protocol itself; in other words, it is actually an
> interoperability issue, not to mention a security issue, if a client sends
> an initial SASL authentication command without first checking, in that
> session, under that security state, what the available mechanisms are.

Agreed.

> The SASL protocol RFC for NNTP will therefore say that the client MUST
> issue LIST EXTENSIONS first.

Agreed, and it's a job for that RFC, not this one.

Um, agreed *except* the wording needs to make it clear that you MUST issue
LIST EXTENSIONS for security reasons, and the server MUST still accept SASL
commands without it.

> I think that in 11.6, we need to say something about *why* this is all an
> issue.  Here's some new proposed wording for the beginning of that
> section:

This is mostly better than what I had.

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

Fine to here.

>     The
>     server is also permitted to change the results of LIST EXTENSIONS from
>     session to session and therefore 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, if
>     caching results, provide a way to force the cached information to be
>     refreshed.

This bit isn't actually a security consideration. It belongs back in 5.3.2.
Removing it also makes the MUST NOT stand out.

> After the example, say something like:
> 
>     Clients are strongly encouraged to not cache the results of LIST
>     EXTENSIONS and issue the command again at the beginning of every
>     session or state change in the session (such as after MODE READER).

I think that's too strong, and doesn't belong in here.

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

This, however, isn't unreasonable. I've stuck it at the end of 11.6.

Listing of integrated wording to follow.

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