[NNTP] Proposed STARTTLS changes

Ken Murchison ken at oceana.com
Fri Oct 1 08:34:28 PDT 2004


Here are my proposed changes to the text which address two issues:

-  580 is an immediate response *only*.  No response codes are sent 
after TLS negotiation.  This falls in line with the other messaging 
protocols and fixs the asymmetry noted by Clive.

-  Server behavior if it doesn't like the result of the TLS negotiation.


Sorry for the nroff, but its the easiest way to get a diff w/o having 
pagination changes come into play.  Comments?


***************
*** 199,216 ****
   Responses
   .IP
   .in 8
- Initial responses
- .in 11
   .nf
   382 Continue with TLS negotiation
   502 Command unavailable [1]
! .fi
! .IP
! .in 8
! Subsequent response
! .in 11
! .nf
! 580 TLS negotiation failed
   .fi
   .IP
   [1] If a TLS layer is already active, or authentication has occurred,
--- 203,212 ----
   Responses
   .IP
   .in 8
   .nf
   382 Continue with TLS negotiation
   502 Command unavailable [1]
! 580 Can not initiate TLS negotiation
   .fi
   .IP
   [1] If a TLS layer is already active, or authentication has occurred,
***************
*** 234,239 ****
--- 230,240 ----
   Additionally, the server MUST NOT return 483 in response to the
   STARTTLS command.

+ If the server is unable to initiate the TLS negotiation for any reason
+ (e.g. a server configuration or resource problem), the server MUST
+ reject the STARTTLS command with a 580 response. Otherwise, the server
+ issues a 382 response and begins a TLS negotiation with the client.
+
   If the client receives a failure response to STARTTLS, the client must
   decide whether or not to continue the NNTP session.  Such a decision is
   based on local policy.  For instance, if TLS was being used for client
***************
*** 269,279 ****
   .ne 4
   2.2.2.1. Processing After the STARTTLS Command
   .IP
! After the TLS handshake has been completed, both parties
! MUST immediately decide whether or not to continue based on the
! authentication and privacy achieved.  The NNTP client and server may
! decide to move ahead even if the TLS negotiation ended with no
! authentication and/or no privacy because NNTP services are often
   performed without authentication or privacy, but some NNTP clients or
   servers may want to continue only if a particular level of
   authentication and/or privacy was achieved.
--- 270,280 ----
   .ne 4
   2.2.2.1. Processing After the STARTTLS Command
   .IP
! After the TLS handshake has been completed, both parties MUST
! immediately decide whether or not to continue based on the
! authentication and privacy achieved (if any).  The NNTP client and
! server may decide to move ahead even if the TLS negotiation ended with
! no authentication and/or no privacy because NNTP services are often
   performed without authentication or privacy, but some NNTP clients or
   servers may want to continue only if a particular level of
   authentication and/or privacy was achieved.
***************
*** 282,294 ****
   is not high enough for it to continue, it SHOULD issue a QUIT
   command immediately after the TLS negotiation is complete.  If the NNTP
   server decides that the level of authentication or privacy is not high
! enough for it to continue, it SHOULD do at least one of (1) close the
! connection, being aware that the client may interpret this behavior as a
! network problem and immediately reconnect and issue the same command
! sequence, or (2) keep the connection open and reply to NNTP commands
! from the client with the 483 response code (with a possible text string
! such as "Command refused due to lack of security"), however this
! behavior may tie up resources unacceptably.

   The decision of whether or not to believe the authenticity of the other
   party in a TLS negotiation is a local matter.  However, some general
--- 283,294 ----
   is not high enough for it to continue, it SHOULD issue a QUIT
   command immediately after the TLS negotiation is complete.  If the NNTP
   server decides that the level of authentication or privacy is not high
! enough for it to continue, it SHOULD reject further NNTP commands from
! the client (other than a QUIT command) with a 483 response code (with
! a possible text string such as "Command refused due to lack of
! security"), but it MAY reject a command with a 400 response code (with
! a possible text string such as "Connection closing due to lack of
! security") and close the connection.

   The decision of whether or not to believe the authenticity of the other
   party in a TLS negotiation is a local matter.  However, some general


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