ken at oceana.com
Tue Mar 9 07:45:05 PST 2004
Clive D.W. Feather wrote:
> 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.
Let me say that I've never been a fan of the RFC 3207 text which Jeff
has based this draft on because of its wordiness and ambiguities such as
this. I think the text in RFC 2595 is simpler and sufficient.
The server has complete control over the negotiation. Its provides a
list of options from which the client can choose. The server should
only provide those options that it is willing to accept, and shouldn't
have to decide *after* the negotiation is complete whether or not it is
happy with the outcome. As a result, I think the case where TLS
negotiation is successful but the server then refuses other commands
with 483 (or some other code) is, and should be, nonexistent. Either
TLS succeeds, or it fails, period. Obviously, if TLS fails, then
issuing 483 for subsequent commands makes sense, but the client should
already expect this.
> 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
I believe I addressed this above. I think any/all text hinting that
this is a possibility (TLS success but server unhappiness) should be
removed. Again, I suggest that RFC 2595 be used as a model, since I
would assume that TLS would be used mostly by reading clients (akin to
IMAP, POP3) rather than feeding clients (akin to SMTP).
>>>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
> 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.
I disagree. This is the model used in several similar and widely
deployed protocols. Let's not try to do something different.
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
More information about the ietf-nntp