Subject: [NNTP] Proposed STARTTLS changes

From: ken at oceana.com (Ken Murchison)
Date: Fri Oct 1 08:34:25 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

---

From: ken at oceana.com (Ken Murchison)
Date: Fri Oct 1 08:38:05 2004

I also removed the following paragraph:

"If the TLS handshake fails in such a way that it is possible to recover
the underlying NNTP session, the server will send a 580 response
(without encryption), beginning with the first post-handshake octet."

---

From: ken at oceana.com (Ken Murchison)
Date: Fri Oct 1 12:28:02 2004

Sorry for replying to my own post again, but I also tweaked the 3 examples:

Example of a client being prompted to use encryption and negotiating it
successfully (showing the removal of STARTTLS from the extensions list
once a TLS layer is active), followed by a successful selection of the
group and an (inappropriate) attempt by the client to initiate another
TLS negotiation:

[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] STARTTLS
[S] OVER
[S] .
[C] GROUP local.confidential
[S] 483 Encryption or stronger authentication required
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation occurs here]
[Following successful negotiation, traffic is via the TLS layer]
[C] LIST EXTENSIONS
[S] 202 Extensions supported:
[S] OVER
[S] .
[C] GROUP local.confidential
[S] 211 1234 3000234 3002322 local.confidential
[C] STARTTLS
[S] 502 STARTTLS not allowed with active TLS layer

Example of a request to begin TLS negotiation declined by the server:

[C] STARTTLS
[S] 580 Can not initiate TLS negotiation

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

[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation is attempted here]
[Following failed negotiation, traffic resumes without TLS]
[C] GROUP local.confidential
[S] 483 Encryption or stronger authentication required
[C] GROUP local.private
[S] 400 Closing connection due to lack of security

---

From: jeff at litech.org (Jeffrey M. Vinocur)
Date: Sun Oct 3 16:30:50 2004

On Oct 1, 2004, at 11:34 AM, Ken Murchison wrote:

> [...]

Some phrasing suggestions below, but with regard to substance, I'm 
happy with the proposed diff.

> + issues a 382 response and begins a TLS negotiation with the client.

Suggest:  "...the server issues a 382 response, and TLS negotiation 
begins."

> ! no authentication and/or no privacy because NNTP services are often

Perhaps "...ended without authentication and/or without privacy 
because..." or something like that?

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: clive at demon.net (Clive D.W. Feather)
Date: Mon Oct 4 00:34:28 2004

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), either by continuous use of
    the 483 response code (possibly with a text string such as "Command
    refused due to lack of security") or by closing the connection after
    issuing a 400 response code (possibly with a text string such as
    "Connection closing due to lack of security").

That is:

(1) Change the structure from "If ... it SHOULD ... but it MAY ..." to
"If ... it SHOULD ... either ... or ...".

(2) Change "with a possible text" to "possibly with a text", since there's
no requirement for any text at all.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: rra at stanford.edu (Russ Allbery)
Date: Mon Oct 4 12:37:01 2004

> group and an (inappropriate) attempt by the client to initiate another

Sorry for the belated note, but yes, this and the new wording look fine to
me.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>