ietf-nntp Draft 20 pre-release 2

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

> My belief is that the general consensus was:

> * Some people want caching of common capabilities while others see it as
> a waste of time. Therefore a client MAY cache.

> * Servers make absolutely no guarantees. Therefore you MUST NOT rely on
> the cached information; you can only use it to drive heuristics.

> * Security is a whole different kettle of fish. It's a really really bad
> idea to cache knowledge about security capabilities rather than checking
> each time. This is, at least, a SHOULD NOT matter if not a MUST NOT
> matter (see previous email).

> Does anyone actually disagree with any of the above three points?

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.

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

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:

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

and then go into the example of why this is a security issue.

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

Rob, what would you think of this as wording for that section?  Would that
make you feel more comfortable?

The specific use case that I have in mind for caching is in an anonymous
news client that opens a new connection to do something like grab OVER
data for the next newsgroup the user is likely to read while the user is
reading news from their main connection.  (I must admit that it's not at
all obvious to me that the time saved is worth it, but on the other hand,
I think it's really good that we're saying something about this because
it's something that NNTP implementors immediately ask questions about.  In
fact, I think language like the above may well be more effective than just
saying "you MUST NOT cache," since it will keep people from just writing
that off as stupid and caching anyway and not thinking about *why*.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>