[NNTP] Re: MODE READER

[Mark Crispin]

On Thu, 4 Nov 2004, Andrew - Supernews wrote:
> Mark> Please expunge this notion of "just try the command and see if
> Mark> it works." It is *extremely* harmful to a protocol to have a
> Mark> mixed mode of capability announcement and "just try."
> I can see we're not going to agree on this.

This is not a matter of opinion.  It is proven fact.

IMAP, POP3, SMTP, ACAP, etc. all have a capability mechanism that works as 
I state.

NNTP, on the other hand, has indeterminate states and an incomplete 
capability mechanism.  To put it mildly, NNTP sucks.

I was hoping that this group was going to fix that.

> It's very common with NNTP to not require authentication at all.
> That's why we have a response code specifically saying "you can't do
> that without starting TLS first" in addition to the one that says "you
> can't do that without authenticating".

That is an obsolete protocol design.  The problem is (as was realized 
during the IMAP2 -> IMAP4 transition) is that the client is obliged to 
undertake many unnecessary RTTs.

RTTs are not your friend.

> When authentication isn't necessary, it's extremely rare (by proportion
> of traffic) for TLS to have any value at all for an NNTP session.

We are rapidly approaching a world in which authentication is always 
necessary.

Yes, I know that Supernews (like many other NNTP service provides) uses 
quick and dirty authentication mechanisms such as IP address validation.

> Mark> TLS is here.  TLS is mandatory.  We need to live with it.
> So you'll be happy to foot the bill?

I'm sorry to be the bearer of bad news, but you will foot the bill, after 
you find itself the victim of an attack that your current authentication 
mechanisms do not prevent.  Your are, in effect, hiding behind a security 
through obscurity shield.

The means of attack are already well-known and implemented.  Currently, 
there are much easier targets for the bad guys.  However, as those targets 
are one-by-one closing their holes, your day of reckoning approaches.

We all have the choice of being reactive or proactive.  We're forced in 
some cases to be reactive.  However, there are other cases in which we can 
be proactive now to save having to be reactive later.

> Mark> There is ample precedent in other protocols: MIME and IMAP have
> Mark> both done it, and quite successfully.
> MIME did it? where?

MIME boundary delimiters.  I know because I invented them.

All the same arguments were made against MIME boundary delimiters because 
the string in the delimiter could appear in the MIME segment (those who 
held this position argued for a count of "lines").  The successful 
counter-argument was that it was easily possible to generate a boundary 
delimiter with the chance of a false hit mathematically small enough to be 
disregarded.

Later, BASE64 and QUOTED-PRINTABLE made it possible to create boundary 
delimiters which could not appear in MIME segments that used those 
transport encodings.  However, since not all segments use these transport 
encodings, it has to fall back on unlikelihood.

> Mark> Removal of extraneous RTTs is always a good thing.
> Only where it doesn't break stuff.

However, in this case nothing is being broken.  The client can still do 
the RTT-costly method.

> >> 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.
> Mark> Is it really just one server, inn, that has this issue?
> I believe so. However, you have to understand the _reason_ why that is
> so

I understand perfectly.  It's an implementation issue in one server. 
That is a remarkably poor excuse for something which costs multiple RTTs 
per session for every client.

If a mode switch was needed to separate clients from peers, why isn't the 
burden on peers?

> Mark> It certainly is not "impossible to conform to the spec";
> It would be impossible to conform to the spec (sans MODE READER)
> without taking away features that people are, in fact, using quite
> widely.

Just what "features" are "taken away"?

> I agree that MODE READER is an extremely annoying wart, but it exists
> for a specific reason, and you can't legislate that reason out of
> existence.

No, but competant programmers can fix the servers so that they do not have 
this problem.

-- Mark --

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