[NNTP] Re: MODE READER
mrc at CAC.Washington.EDU
Thu Nov 4 11:41:30 PST 2004
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
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
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
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
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
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
No, but competant programmers can fix the servers so that they do not have
-- Mark --
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
More information about the ietf-nntp