[NNTP] draft-ietf-nntpext-tls-nntp-02.txt

[Ken Murchison]

Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
> 
>>Russ Allbery said:
> 
> 
>>>I don't see how.  580 doesn't mean that the connection is closing,
>>>whereas 400 does, does it not?
> 
> 
>>That's the point. The server then has a choice, something like this:
> 
> 
>>    If the TLS handshake fails in such a way that it is possible to
>>    recover the underlying NNTP session, the server will send a
>>    response (without encryption), beginning with the first post-
>>    handshake octet. If the server is willing to continue the connection
>>    the response code 580 MUST be used; if not, the response code 400
>>    MUST be used and the server MUST then close the connection.

Note that the option of closing the connection is something that is not 
present in RFC 3207 (on which most of this text is based).  It was added 
by Jeff because he felt that servers may not want to have client beating 
on them after a failed TLS.  I never really liked this text and would 
prefer to just stick with the original RFC 3207 text (just issue 483 
responses to subsequent commands).  Doesn't the base doc already allow 
servers to unilaterally terminate the connection and addresses how to do 
this?  If so, do we need to address this in the STARTTLS doc?


> 
>>So we get four cases:
>>* succeeded: no response, client's turn
>>* failed, session recovered, server will continue     -> 580 response
>>* failed, session recovered, server will not continue -> 400 response
>>* failed, session can't be recovered, close connection (?)
> 
> 
> Yeah, I see your point.  I think that originally we had the server
> responding after the completion of the TLS handshake, and then that was
> removed for some reason (maybe because other protocols didn't have it).

Correct.


> 
> IMAP has asynchronous replies, so what it does doesn't help.  POP doesn't
> have any server response after the TLS negotiation; it either succeeds or
> fails, but the server only sends -ERR before it even tries (it sends
> either -ERR or +OK and then, if it sent +OK, goes immediately into the TLS
> negotiation).  SMTP also says that the server responds immediately to the
> STARTTLS command and then the TLS handshake begins following that
> response.  It does not allow the server to send any response following
> completion of the TLS handshake.
> 
> None of the other protocols that use STARTTLS appear to allow the server
> to send a response after the STARTTLS negotiation.  I think that the first
> paragraph of 3.2.2 doesn't actually belong in 3.2.2.

I believe that someone wanted this text added to clarify that the 580 
response would be unencrypted.  I think it should be obvious that if the 
TLS negotiation failed, that we don't have encryption, so I'm open to 
removing this paragraph, or moving it elsewhere if we want to keep the 
clarification.


> In fact, I think
> that we can drop it completely, since it arises via a difference in
> wording between our draft and SMTP.  We say:
> 
>      After the TLS handshake has been completed successfully, both
>      parties MUST immediately decide whether or not to continue based on
>      the authentication and privacy achieved.
> 
> SMTP says (RFC 3207):
> 
>      After the TLS handshake has been completed, both parties MUST
>      immediately decide whether or not to continue based on the
>      authentication and privacy achieved.
> 
> Note the absence of the word "successfully."  I think we should just adopt
> the SMTP language, which makes the problem go away -- a failed TLS
> handshake that allows recovery of the NNTP session is then completion of
> the TLS handshake, with no authentication and privacy achieved, and the
> client and server should then proceed as described in 3.2.1.  We can say
> something explicit about that if it seems useful.

Agreed.


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