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

[Ken Murchison]

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.

See above.


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

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