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

[Clive D.W. Feather]

Russ Allbery said:
>> (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.

No. At least, I don't think so.

I don't know the details of TLS, so I don't know whether one side advertises
capabilities and the other side picks, or if one side requests something
and the other side makes a counter-offer, or what. But what the present
text says is, summarised:
- the negotiation was successful;
- the server is unhappy with the situation.
It's not at all clear to me that the client *knows*, through TLS, why the
server is unhappy, and the text even says that:

    the client may interpret this behavior as a network problem and
    immediately reconnect and issue the same command sequence

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

This would be my preference *if* the present flow of control is set in
stone.

However, I'm a little bothered by the asymmetry between TLS failure, where
the *server* moves next (issuing a response code), and success, where the
*client* moves next (issuing a command). If this isn't cast in stone, then
I would strongly suggest making it always the server. This has an
additional benefit: you can specify that, after TLS negotiation ends
successfully, both sides return to the NNTP initial connection state with 
the server issuing an initial greeting. I suspect this will make things
easier for client design.

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