[ietf-nntp] draft-ietf-nntpext-tls-nntp-01.txt

[Clive D.W. Feather]

Russ Allbery said:
>> Section 2: it's not clear from this document why STARTTLS is forbidden
>> after a successful authentication has been organised.
> This is the way that STARTTLS is specified for other protocols.
[...]

Okay, but I think there should be some explanatory text.

>> Section 3.2: I would delete the second sentence of the first paragraph,
>> relying on the base specification, or at least the bit before the
>> semicolon. We don't talk about sockets, just connections, and because
>> the connection will switch to the TLS protocol, talking about sending
>> anything else is premature.
> 
> I would delete the part before the semicolon but leave the rest of this,
> since I think it's useful to make no pipelining explicit.

But it's clearly stated at the start of the command description.

>> Section 3.2.1: Rather than "... it SHOULD do at least one of (1) close
>> ..."  I think you are better saying "... it SHOULD keep the connection
>> [text of (2)] or MAY close the connection [text of (1)]". That is, make
>> it clear that (2) is better.
> Why is it obvious to you that (2) is better?  That's not clear to me; I'm
> not sure which of those is better and would want some practical experience
> first to be able to figure that out.

(2) involves providing an explicit indication of a problem. (1) doesn't;
the draft even points out that a client might reasonably assume it was a
transient network failure and try again. I can't see any sensible way for a
client to determine which of the two applies if the connection closes
during a STARTTLS command.

In fact, thinking again, it would appear to me that the optimal behaviour
for the server in this situation is:
- respond to the first NNTP command with "483 not enough security"
- respond to the second NNTP command with "400 not enough security".
That minimizes the resource tie-up mentioned as a problem with (2) while
making it clear there's a problem.

Alternatively, does this indicate that the STARTTLS model is wrong - the
protocol should start with a *server* response, with 502-and-close meaning
that it doesn't like the connection state.

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