[NNTP] LIST EXTENSIONS (again)

[Mark Crispin]

On Tue, 9 Nov 2004, Russ Allbery wrote:
> Ah, I didn't realize that you did also do reactive authentication.

Indeed I do, both in NNTP and SMTP.  AFAIK, I coined the term.

> Yes, if you also do
> reactive authentication, this implementation works in that mode.  If,
> however, the user does specify /user=xxx to force authentication, that
> authentication would fail in this situation since it would be done against
> the transit server component.

Yup, and when it happens I blame the server.

> If your client does have everything enabled and sends, as you described
> earlier:
>    STARTTLS
>    AUTHINFO
>    MODE READER
> in that order to an INN server in a situation that actually requires MODE
> READER, STARTTLS would fail, AUTHINFO would fail, and then MODE READER
> would actually give you a reader connection.  I expect that this would
> throw some sort of error to the user in Pine (and, in fact, I expect that
> this configuration of Pine wouldn't proceed after STARTTLS failed).

Right.  Servers should not advertise STARTTLS if they don't accept it.

> This is a great illustration of why we needed a real NNTP standard years
> ago, since the implementation that you (quite reasonably) arrived at via
> experimentation was, in fact, always broken and never would have worked
> properly in the situation you were attempting to allow for.

My client implementation is not broken.  It is forced to send AUTHINFO 
first by the Diablo server, and (in real life) inn servers don't force 
MODE READER first.

Nor is my client broken because inn can be configured to break my client. 
inn is not the arbitrar on what is broken.

Nor is inn broken.

Nor is Diablo broken.

The NNTP protocol is what is broken.  This is the part that many people 
seem not to understand.  Protocols that create non-interoperability are 
broken.  That is why we need to fix NNTP.

> It is indeed the fault of the NNTP
> community and the INN developers for not documenting MODE READER clearly
> enough so that both you and Diablo made different, apparently reasonable
> mistakes in implementation (although Diablo's mistake is frankly less
> reasonable than yours).

It was not a mistake, for the simple reason that MODE READER was not 
documented!

It is a painful lesson to learn that, by failing to document a facility, 
the original deployer forfeits the ability to call differing 
implementations broken.  Trust me; I learned *that* particular lesson the 
hard way.  Let's you and I down that sixpack and we'll commiserate with 
our respective war stories.  We can play that fun game of "who has the 
worse tale of woe"... :-)

>> The fact still remains that MODE READER itself is a broken, and that it
>> is not permissible to require MODE READER before STARTTLS since TLS does
>> a complete reversion to initial connection state.
> Could you point me at where this is documented?  I'm aware that it
> requires discarding all information about server capabilities and all
> authentication credentials, but this is a stronger statement that I don't
> recall seeing in the documents that I've read.

That's what I was told when similar issues came up in IMAP and SMTP. 
Everything had to be reset.

If you think about it, it only makes sense.  Otherwise, you don't really 
know that MODE READER actually happened, as opposed to having been seized 
by an MITM.  Although I don't think there is much (beyond harassment) that 
could happen by attacking this, a bad guy could certainly cause a great 
deal of confusion!

-- Mark --

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