[NNTP] Re: MODE READER

Mark Crispin mrc at CAC.Washington.EDU
Thu Nov 4 09:27:25 PST 2004


On Thu, 4 Nov 2004, Andrew - Supernews wrote:
> OK, it occurs to me that we can simplify that a lot by allowing the
> LIST EXTENSIONS output to indicate one of three explicit conditions:
> 1) that MODE READER isn't necessary (which will be a very common case)
> 2) that MODE READER really is necessary (but might fail)
> 3) that MODE READER isn't possible, and nor are any reader commands (which
> will be true for transit servers with no reader support at all, or where
> the connecting IP can never obtain reader access)

This is a good idea.

> In existing practice, ignoring the above proposal, it's actually not
> unreasonable for clients to do MODE READER before the first LIST
> EXTENSIONS, since the MODE READER shouldn't get a 480 response (and
> if it does, you can do LIST EXTENSIONS then before authenticating).
> But the spec certainly doesn't lead an implementor to do it that way.

Sigh.  Once again, we fall into the trap of talking about how to work 
around existing warts, rather than moving forward.

> - the client doesn't have to do LIST EXTENSIONS before STARTTLS if it
>   wants to initiate TLS on its own initiative rather than at the
>   server's request.

No!!!  The client must know that the server supports a non-mandatory 
command before issuing it.  That is the entire point of a capability 
announcement mechanism.

Please expunge this notion of "just try the command and see if it works." 
It is *extremely* harmful to a protocol to have a mixed mode of capability 
announcement and "just try."

> - if the client doesn't want to initiate TLS but the server wants to
>   force it to do so, your suggested exchange doesn't make any sense.

In all protocols, a server forces TLS by requiring authentication and not 
advertising any authentication mechanisms until TLS is in force.

In all protocols with the exception of NNTP, TLS is forced unless the 
server has an authentication mechanism that does not exchange passwords in 
the clear.  Even then, it is advisable to use TLS since it is absolutely 
trivial to hijack sessions.

>   (It's important that servers not encourage clients to initiate TLS
>   unnecessarily, since that leads to overhead that can only be avoided
>   by disabling TLS altogether.)

TLS is here.  TLS is mandatory.  We need to live with it.

Statements to the effect of "security isn't as important in this protocol" 
are going to be met with very harsh responses from people who have fought 
this battle many times before.

Yes, indeed, this battle has been fought many times before; your argument 
has been advanced many times before; and it's been thoroughly crushed many 
times before.  Hard feelings have very commonly resulted.

It would be a benefit for all of our blood pressures if we can learn the 
lessons from the past, decide not to fight this battle, and accept the 
outcome from this battle in every other protocol.

> There are two fundamental objections to that. First is that you're
> assigning semantics to fields which in the deployed specification are
> explicitly designated as containing arbitrary non-semantic text.

There is ample precedent in other protocols: MIME and IMAP have both done 
it, and quite successfully.

Removal of extraneous RTTs is always a good thing.

> The
> second is that you can't just handwave MODE READER out of existence;
> if you make it impossible to conform to the spec, then people will
> just not bother conforming to the spec and will stick with the
> established practice.

Is it really just one server, inn, that has this issue?

It certainly is not "impossible to conform to the spec"; and adding an 
unnecessary RTT to every NNTP interchange for the benefit of a single 
server implementation is an extremely poor idea.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.



More information about the ietf-nntp mailing list