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

[Russ Allbery]

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.

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

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

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>