[NNTP] Notes on auxiliary documents

[Clive D.W. Feather]

Ken Murchison said:
>> The core specification never includes generic responses in the pro-forma 
>> sections for each command (unless they have some unusual meaning, such 
>> as 502 for MODE READER).

> 502 is listed in both AUTHINFO and STARTTLS pro-forma sections to make 
> it clear that it also applies after these commands have been used (per 
> the notes).  I'm pretty sure this was discussed before and it was signed 
> off on.

Hmm, I don't recall offhand.

>> Section 2.2: "Servers are not required to accept unsolicited 
>> authentication". I don't follow this. Since the server advertises its 
>> conformance with this document (through CAPABILITY / LIST EXTENSIONS), 
>> it is soliciting authentication. The only way I can read this is that, 
>> despite that, authentication is not permitted *until* a 480 happens. Um:
>> 
>>     [C] LIST EXTENSIONS
>>     [S] 202
>>     [S] AUTHINFO USER SASL:EXTERNAL
>>     [S] .
>>     [C] AUTHINFO USER fred flintstone
>>     [S] 481 unsolicited authentication rejected (or is it 503?)
>>     [C] GROUP secret.group
>>     [S] 480 need to authenticate
>>     [C] AUTHINFO USER fred flintstone
>>     [S] 281 Hello Fred.
>> 
>> Surely that can't be desirable?
> 
> Correct, I think this is what Jeff is trying to say.  That the client 
> can go ahead and authenticate without having received a 480 response and 
> the server must accept authentication even is not prompted by a 480. 

Okay, that's good.

> Essentially, this sentence is to be paired up with the first sentence of 
> the previous paragraph.

So by "unsolicited" you actually mean something like AUTHINFO PASS after
the AUTHINFO USER was rejected, or carrying on the SASL exchange after a
48x. The latter is just going to confuse the server, and the former has an
error code already.

> I'll gladly take some suggested text, unless you feel that this sentence 
> can be deleted entirely.

If I'm still on track, I don't think we need it. It's like saying that the
client mustn't send the article body if POST doesn't get the 354 code.

>> Section 2.4.2: I know that we've discussed this before, but I think the 
>> code for "don't handle this mechanism" shouldn't be 501 but, rather, 503 
>> or something AUTHINFO-specific.
> This has already been changed.  Did you see my "proposed changes" posts?

Yes, but obviously overlooked this one when writing this message.

>> Just above the wording you changed, I suggested that "if a security 
>> layer as part of the authentication," be deleted after "In agreement 
>> with [SASL]". If this ability is useful (I'm still agnostic), then it 
>> could be useful in other circumstances as well.
> Continuing to advertise only makes sense when a security layer is 
> advertised, since the info can be trusted otherwise (a MiM attack could 
> still be in progress).

I still think this is wrong (and, indeed, how we advertise this is the
wrong approach), but I'll leave it.

>> Sections 2.4.2 and 6: we say that the server MUST discard all knowledge. 
>> Does this include NNTP state? E.g.
>> 
>>     [C] GROUP a.group
>>     [S] 211 10 555 666 a.group selected
>>     [C] AUTHINFO SASL MECHANISM
>>     [SASL details omitted, security layer created]
>>     [S] 281
>>     [C] ARTICLE 10
>> 
>> Does the server respond with 220 or 412? Whichever the answer is, it 
>> needs to be made more clear.
> 
> That's a good question.  This wording comes from the other SASL profile 
> docs (IMAP, POP, SMTP) in which authentication usually (always?) happens 
> before other commands.
> 
> I don't *think* that server has to go back to the "unselected group" 
> state after auth, but my guess is that if the client authenticates in 
> the middle of a session its because they are trying to access a group 
> that returned a 480 and therefore will be changing groups immediately 
> after auth.

Well, yes, but we can't guarantee it and so can't rely on it. There may
also be other server state either now or in the future.

I don't mind whether it's "server must forget all state", or "server must
retain all NNTP state", but we need to be absolutely clear. Oh, and TLS
needs to be consistent with SASL on this.

[I'd prefer "retain state", because it may not be obvious to the main NNTP
engine in the client whether a security layer was negotiated or not by some
other module, and therefore whether the state was retained or not.]

>> Section 3.1: in the last paragraph, insert ", both exclusive, after 
>> "between the first ... CRLF".
> I don't understand what change your are requesting (you only have 3 
> quotes in your suggestion).

Sorry, it comes of writing the material on a cramped aircraft.

Change:
    "between the first ... CRLF ..."
to:
    "between the first ... CRLF, both exclusive, ...

>> Section 6, last paragraph: add something like "The minimum strength 
>> acceptable will, of course, depend on specific circumstances and is 
>> outside the scope of this specification." Otherwise it implies there's 
>> some definition of "weak" which we're hiding (just to be perverse?).
> I added: "The minimum strength acceptable is a policy decision which is 
> outside the scope of this specification."

Fine.

>> streaming-02
>> ============
>> I notice that you switch between "pipeline", "stream", and "asynchronous 
>> transfer" with no apparent consistency. We agreed to call the basic 
>> concept "pipelining", and that's what the core document calls it. You 
>> may want to revisit this.
> 
> Please look at my "proposed changes" post and see if it addresses this. 
> Of course, based on Andrew's post, we may have to change this yet again.

I think it might be best to wait until you circulate the next draft (or a
snapshot in the way I do) and then do a full sweep.

>> Section 1 (and possibly elsewhere) talks about "server-to-server". NNTP 
>> doesn't have server-to-server links. Again, we should be consistent and 
>> only say "peer-to-peer" and "client-to-server".
> I fixed the two instances in Section 1.  I believe the wording is 
> correct elsewhere.

I didn't make a full scan for this, just noted it as I was writing (I blame
the cramped plane again).

>> Section 2.3.2 gives too much emphasis on non-conforming implementations. 
>> Replace it completely with something very similar to:
>> 
>>     On a server which conforms to this specification, the MODE STREAM
>>     command MUST return a 203 response (or 501 if an argument is given)
>>     and MUST NOT have any other effect.
>> 
>>     Historic note: some old server implementations did not advertise
>>     streaming in the response to LIST EXTENSIONS but provided CHECK and
>>     TAKETHIS commands similar or identical to those in this document.
>>     Clients could test for this by issuing the MODE STREAM command; if
>>     it succeeded, pipelining was possible. However, even if the command
>>     succeeded it does not mean that the CHECK and TAKETHIS commands
>>     conform to this specification. Clients SHOULD use the CAPABILITY
>>     command to determine server capabilities.
> 
> First off, I think Russ signed off on the current text, but I'm willing 
> to clarify if needed.  In fact, I like most of what you have above.
> 
> This is a similar situation to MODE READER.  We are trying to steer new 
> implementations away from MODE STREAM but document its prior use.

Right. One thing that's happened since that text was written is that we've
gone for a much more solid distinction between conforming-to-our-texts and
older servers. For example, an NNTPv2 server now MUST NOT advertise
STREAMING in LIST EXTENSIONS unless it conforms to your document. So we can
sensibly say it's a no-op, conforming clients don't need to use it with
conforming servers, but there's a historic compatibility issue.

I'll be taking the same approach with MODE READER if you lot decide to
change INN not to need it.

>> Section 2.4.2: is "another client is sending the same article" the best 
>> example? Surely "disc full" or something like that would be better.
> I used the wording from your subsequent post.

Okay.

>> Section 2.2.2 para 6: The text "The TLS negotiation begins ... response" 
>> only handles one direction; compare the corresponding text in AUTHINFO 
>> SASL. It should be something like "For the server to client direction, 
>> the TLS negotiation ... response; for client to server it begins with 
>> the next octet sent after the CRLF at the end of the command."
> I don't see the confusion.  For both client and server the negotiation 
> starts after the CRLF.  The same wording (except for "octet") is in IMAP 
> and POP.

Hmm.

>> In the following paragraph, surely "MUST discard" should be "SHOULD NOT 
>> rely on", since the client can still make heuristic decisions.
> I'm not sure about this.  Based on Mark's comments from the MODE READER 
> thread, I *think* that this is almost a requirement of TLS (whether 
> implicitly or explicity, I don't know).

We discussed this a while ago when talking about whether clients had to
resend LIST EXTENSIONS in various places. Security considerations mean that
you mustn't rely on previous information, but it's sensible to use it for
heuristic decisions - so long as you're prepared for failure - and even for
security checks. That "do not rely on" wording is in the core document
IIRC.

>> Section 5 para 3: you've got two sentences beginning "Further,"; I would 
>> omit the first instance. And the last sentence needs something like "or 
>> vice versa" at the end.
> Sentence removed,

Um, I didn't mean remove the sentence, just the word "Further" (before
"because delivery").

> not sure what "vice versa" gets us.

The sentence basically tells server authors that they can't trust the
ultimate origin of material sent via IHAVE/POST/TAKETHIS just because
they know who the client is. Fine.

But don't TLS and SASL allow the client to check it's talking to the true
server? If so, the fact that it is doesn't mean that the server has checked
the origin of articles sent via ARTICLE either. Hence "or vice versa".

-- 
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            |                            |