[NNTP] Proposed changes to draft-ietf-nntpext-tls-nntp-03

[Ken Murchison]

Changes from Previous Version:

   Changed:
   o  Neither 480 nor 483 are valid responses to STARTTLS.
   o  Removed requirement that the client SHOULD send a LIST EXTENSIONS
      immediately after a successful TLS.
   o  Changed reference to IANA requirements in [NNTP] from Section 8 to
      Section 8.1.

   Clarified:
   o  If the server doesn't like the results of TLS, it only sends 483
      response to restricted NNTP commands (e.g. QUIT, HELP, LIST
      EXTENSIONS are excluded).


Relevent text diff:

@@ -219,7 +213,7 @@
  STARTTLS is not a valid command (see section 2.2.2.2).
  .IP
  NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT return
-483 in response to STARTTLS.
+either 480 or 483 in response to STARTTLS.
  .LP
  2.2.2. Description
  .IP
@@ -233,8 +227,8 @@
  a connection with these properties.  The client MAY therefore send
  STARTTLS after receiving a 483 response; the client also MAY decide to
  send STARTTLS without previously receiving a 483 response.
-Additionally, the server MUST NOT return 483 in response to the
-STARTTLS command.
+Additionally, the server MUST NOT return either 480 or 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
@@ -289,8 +283,8 @@
  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 either reject further NNTP commands from
-the client (other than a QUIT command) with a 483 response code
+for it to continue, it SHOULD either reject subsequent restricted NNTP
+commands from the client with a 483 response code
  (possibly with a text string such as "Command refused due to lack of
  security"), or reject a command with a 400 response code (possibly
  with a text string such as "Connection closing due to lack of
@@ -330,8 +324,7 @@
  and article number, that was not obtained from the TLS negotiation
  itself.  The client MUST discard any knowledge obtained from the server,
  such as the list of NNTP service extensions, which was not obtained from
-the TLS negotiation itself.  The client SHOULD send a LIST EXTENSIONS
-command as the first command after a successful TLS negotiation.
+the TLS negotiation itself.

  The extensions returned in response to a LIST EXTENSIONS command
  received after the TLS handshake MAY be different than the list returned
@@ -391,7 +384,8 @@
  Example of a failed attempt to negotiate TLS, followed by two attempts
  at selecting groups only available under a security layer (in the
  first case the server allows the session to continue, in the second it
-closes the connection):
+closes the connection).  Note that unrestricted commands such as LIST
+EXTENSIONS are unaffected by the failure:
  .IP
  .in 8
  .nf
@@ -399,6 +393,11 @@
  [S] 382 Continue with TLS negotiation
  [TLS negotiation is attempted here]
  [Following failed negotiation, traffic resumes without TLS]
+[C] LIST EXTENSIONS
+[S] 202 Extensions supported:
+[S] STARTTLS
+[S] OVER
+[S] .
  [C] GROUP local.confidential
  [S] 483 Encryption or stronger authentication required
  [C] GROUP local.private

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