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

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:
> 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.

I don't know that we necessarily have an explanation that would be
succinct and interesting.  Looking at other protocols, they all say
basically the same thing that we say.

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

Oh, good point.

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

The client knows that the server requested more encryption and the client
turned it down, doesn't it?  Hm.

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

This is a reasonable alternative solution to propose.  I wouldn't mind
seeing that in the draft.

I'm still not sure that we really want to recommend one approach or
another, since I do think the client has enough information from the TLS
negotiation to know why things failed.  But maybe I'm wrong.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>