ietf-nntp LIST EXTENSIONS non-pipelined and non-cacheable?

[Peter Robinson]

Ken Murchison <ken at oceana.com> wrote:

> Overall, I think shortcuts like the ones you propose below are a bad 
> idea, and the potential risks outweight the perceived rewards.  Details
> below.

I agree when it comes to authentication/privacy extensions, but not for
less 'sensitive' ones.

> Peter Robinson wrote:
> 
> > | 5.3 LIST EXTENSIONS
> > 
> > | This command MUST NOT be pipelined.
> > 
> > Why not?  I can understand that a client should wait until the LIST
> > EXTENSIONS response before trying to use an extension (or not), but why
> > shouldn't it do something like this:
> > 
> >  [C] LIST EXTENSIONS
> >  [C] GROUP misc.test 
> >  [S] 202 Extensions supported:
> >  [S] OVER
> >  [S] HDR 
> >  [S] .
> >  [S] 211 1234 3000234 3002322 misc.test
> >  [C] OVER
> > (...)
> > ?
> 
> I suppose it would be reasonable to allow pipelining LIST EXTENSIONS 
> with base (mandatory to implement) commands ONLY, but you just know that
> some poorly written client will try to pipeline something that it 
> shouldn't (e.g., AUTHINFO USER/PASS before realizing that its not 
> supported).

But that's no worse than the current situation where the client doesn't
have to bother (not even 'SHOULD') sending LIST EXTENSIONS at all before
trying AUTHINFO USER/PASS.

> > | It is not required that the client issues this command before
> 
> FWIW, I also think that this is a bad idea, especially with AUTHINFO 
> commands.  Perhaps the text should state something to this effect.

I think that is a reasonable (and consistent) position.

[...]

> > It seems inconsistent that on one hand, a client can (try to) use an
> > extension having no idea whether it's supported, while on the other hand
> > it is forbidden to cache the LIST EXTENSIONS response, and use it to
> > make an educated guess.
> > 
> > I'd have thought that that kind of decision should be left to newsreader
> > authors and users.  So 
> 
> No!  A client should always check the available extensions and be 
> flexible enough to handle changes from session to session.
> 
> If a client caches the info, then it can potentially do something 
> stupid, like expose a user's plaintext password.

Yes.  When it comes to security/privacy, I agree wholeheartedly.  But I
am thinking of the case of a user using the news server of their
connectivity provider (IP-based authentication) and posting to Usenet
(i.e. in public).  If the client only wants to use LIST EXTENSIONS to
determine whether it can use OVER or HDR, it seems reasonable to cache
the LIST EXTENSIONS response (for a day or a week maybe) which is
neither sensitive nor likely to change frequently.  Of course the client
must be able to cope with those commands failing unexpectedly.

> For example, consider this conversation:

[snip]

> If the client caches the last LIST EXTENSIONS response, then the next
> time that it goes to authenticate (w/o checking LIST EXTENSIONS), it 
> will try to do so in the clear, which is "not a good thing":

No it is not.  If the client is using LIST EXTENSIONS to decide whether
and how to provide security (privacy or authentication) then it becomes
much more important.  

I suggest, as far as the base nntp draft is concerned, that LIST
EXTENSIONS SHOULD be issued before using non-base commands, that it MAY
be pipelined before base commands, but MUST NOT be pipelined before
extensions.  The privacy extension documents can make stronger demands
about LIST EXTENSIONS, such as that it MUST be issued before any
security extensions, and that it MUST be reissued after changes in
security.

Just a suggestion.  Perhaps it's too late to be making changes now.

Peter