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

[Ken Murchison]

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


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


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


> | attempting to make use of any extension. The response generated by
> | this command MAY change during a session because of other state
> | information (which in turn may be changed by the effects of other
> | commands). An NNTP client MUST NOT cache (for use in another session)
> | any information returned if the LIST EXTENSIONS command succeeds.
> 
> 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.  For example, consider 
this conversation:

S: 200 eagle.oceana.com Cyrus NNTP v2.2.1-BETA server ready, posting allowed
C: LIST EXTENSIONS
S: 202 Extension list follows:
S: AUTHINFO USER
S: SASL CRAM-MD5 NTLM DIGEST-MD5
S: STARTTLS
S: STREAMING
S: .
C: STARTTLS
S: 382 Begin TLS negotiation now
verify error:num=19:self signed certificate in certificate chain
TLS connection established: TLSv1 with cipher DES-CBC3-SHA (168/168 bits)
C: LIST EXTENSIONS
S: 202 Extension list follows:
S: AUTHINFO USER
S: SASL CRAM-MD5 NTLM DIGEST-MD5 PLAIN
S: STREAMING
S: .
C: AUTHINFO SASL PLAIN a2VuAGtlbgBiYW5hbmEx
S: 281 Success (tls protection)
Authenticated.
Security strength factor: 168


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


S: 200 eagle.oceana.com Cyrus NNTP v2.2.1-BETA server ready, posting allowed
C: LIST EXTENSIONS
S: 202 Extension list follows:
S: AUTHINFO USER
S: SASL CRAM-MD5 NTLM DIGEST-MD5
S: STARTTLS
S: STREAMING
S: .
C: AUTHINFO SASL PLAIN a2VuAGtlbgBiYW5hbmEx
S: 502 no mechanism available
Authentication failed. generic failure
Security strength factor: 0

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp