[NNTP] LIST EXTENSIONS (again)

Clive D.W. Feather clive at demon.net
Tue Nov 9 03:57:39 PST 2004


Okay, this is going to be a rather portmanteau answer to the long LIST
EXTENSIONS thread sitting in my inbox.

Russ says:
> I do think that we want to adopt something out of the discussion that
> Andrew and Mark had about avoiding round trips.

I've posted separately on this.

> At the least, we need
> to advertise whether MODE READER is required.

And this.

> After Mark's messages, I've been convinced that we should mandate the
> order of the state change commands.  The correct order as near as I can
> tell would be:
> 
>     MODE READER
>     STARTTLS
>     AUTHINFO

Right.

> One can also gain a round trip with a different idea, namely having
> successful successful AUTHINFO SASL (which is a new commands, so we can do
> whatever we want with it) include LIST EXTENSIONS output in its response.

This is a specific example of my LEAN suggestion.

>> Approach B: the server lists all the RFCs to which it conforms. The client
>> needs only know a single RFC (unless it has multiple code paths).

> This is equivalent to having NNTPv2, NNTPv3, etc. extension labels that
> can all be advertised together if the revisions are compatible somehow.  I
> think this is the best approach to take.

Right. Except that it would be "_NNTP_ 2 3".

[3977]
>> Russ? Can you have a go at this?
> I'll ask our AD.

Thanks.

>>>> (3) A conforming server MUST NOT advertise any extension label, other
>>>> than one beginning with X, not in the IANA registry.
>> Note, I think that's stronger than what we had before.
> Yes, but I think it's the right thing to do.

Done.

>> Um, I'm not going to swear there's no other significant options that are
>> worth noting here. Can anyone think of any?
> Do we want to get into advertising whether commands are permitted for a
> particular client?  (POST and NEWNEWS are the ones most frequently not
> permitted.)

We've been through this before. NEWNEWS was mandatory in 977 and we agreed
that there was no reason to change it.

We indicate POST through the initial greeting (and MODE READER). However,
authentication could change this, so I'd be in favour of a POST argument to
the _NNTP_ extension label.


Ken:
> The only question that I have is whether these                   
> capabilities are advertised as arguments to NNTPv2 or as standalone
> extension labels?

They're arguments. The model I have is a single "core capabilities" line in
the LIST EXTENSIONS output.

> The only issue would be        
> that if a SASL security layer is negotiated, any extensions returned in
> the response would probably be ignored by the client anyways, since the
> response is sent in the clear.  Only subsequent commands (e.g. LIST
> EXTENSION) are protected by the SASL security layer.

Um, just out of interest, doesn't this mean that the argument of a 283
response is insecure as well?

Can I make a proposal here? It might sound odd, but bear with me.

*IF* an SASL security layer is negotiated, the server replies with two
responses:
* a 180 response meaning "security layer negotiated"
* the 281 or 283 response as normal
with the security layer coming into effect at the end of the 180, *not* the
28x.

So, using {} to indicate a secure connection:

    [C] AUTHINFO SASL WHATEVER
    [S] 383 base64+stuff
    [C] base64+stuff/finishing+the+negotiation+of+a+security+layer
    [S] 180 security layer starting after this line
    {S} 283 base64/additional+data

You can then send the capabilities in a secure way, either Russ's way:

    [C] AUTHINFO SASL WHATEVER
    [S] 383 base64+stuff
    [C] base64+stuff/finishing+the+negotiation+of+a+security+layer
    [S] 180 security layer starting after this line
    {S} 283 base64/additional+data LIST EXTENSIONS data follows
    {S} _NNTP_ 2
    {S} STREAMING
    {S} .

or in accordance with my LEAN proposal:

    [C] LIST EXTENSIONS AUTO
    [S] 101 auto mode activated
    [S] _NNTP_ 2
    [S] AUTHINFO SASL:WHATEVER
    [S] .
    [S] 203 dummy response
    [C] AUTHINFO SASL WHATEVER
    [S] 383 base64+stuff
    [C] base64+stuff/finishing+the+negotiation+of+a+security+layer
    [S] 180 security layer starting after this line
    {S} 101 Updated LIST EXTENSIONS data follows
    {S} _NNTP_ 2
    {S} STREAMING
    {S} .
    {S} 283 base64/additional+data

Incidentally, I know that TLS puts security into effect before NNTP
restarts and that we've said that the *client* gets to go next, but I
wonder if we should put in a 180 response here to provide a hook for server
capabilities, however done:

    [C] STARTTLS
    [S] 382 negotiating
    [TLS layer is negotiated]
    {S} 180 TLS successful

or with LEAN:

    [C] LIST EXTENSIONS AUTO
    [S] 101 auto mode activated
    [S] _NNTP_ 2
    [S] STARTTLS
    [S] .
    [S] 203 dummy response
    [C] STARTTLS
    [S] 382 negotiating
    [TLS layer is negotiated]
    {S} 101 Updated LIST EXTENSIONS data follows
    {S} _NNTP_ 2
    {S} AUTHINFO USER SASL:PLAIN
    {S} .
    {S} 180 TLS successful

I note that Mark writes:
> If we had been clever with TLS, we would have designed STARTTLS so that
> there was an intermediate response (not under TLS) and a final response
> (under TLS)
so I guess he agrees.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |



More information about the ietf-nntp mailing list