rra at stanford.edu
Mon Mar 8 09:55:39 PST 2004
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/>
More information about the ietf-nntp