Subject: [NNTP] Proposed changes to STARTTLS-07

From: Ken Murchison <[email-masked]>
Date: Tue, 02 Aug 2005 11:30:13 -0400

Based on comments from the list and Russ' suggestion, here is my current 
diff for STARTTLS.  Note that a lot of this is just moving text around 
(back to -06 placement).  It feels like we need more text describing 
*why* the connection should be closed after a failed TLS (session in 
indeterminate state, interop problems, etc), but I couldn't come up with 
anything that I like.  Suggested text is welcome.

--- starttls-07.txt	2005-08-02 10:12:03.000000000 -0400
+++ starttls-08.txt	2005-08-02 11:21:43.000000000 -0400
@@ -14,7 +14,7 @@

                            Using TLS with NNTP
-                     draft-ietf-nntpext-tls-nntp-07
+                     draft-ietf-nntpext-tls-nntp-08

  Status of this memo
@@ -56,11 +56,10 @@

  Note to the RFC Editor

-     The normative references to RFC 2234, RFC 2246, and RFC 3546, and the
-     informative reference to RFC 2222 may
-     be replaced by draft-crocker-abnf-rfc2234bis,
-     draft-ietf-tls-rfc2246-bis draft-ietf-tls-rfc3526bis, and
-     draft-ietf-sasl-rfc2222bis
+     The normative references to RFC 2234, RFC 2246, and RFC 3546,
+     and the informative reference to RFC 2222 may be replaced by
+     draft-crocker-abnf-rfc2234bis, draft-ietf-tls-rfc2246-bis
+     draft-ietf-tls-rfc3526bis, and draft-ietf-sasl-rfc2222bis
       respectively should any or all of those documents reach RFC status
       before this one.

@@ -205,10 +204,26 @@

       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 TLS negotiation
-     begins.  A server MUST NOT under any circumstances reply to a
-     STARTTLS command with either a 480 or 483 response.
+     server MUST reject the STARTTLS command with a 580 response, and
+     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
+     subsequent restricted command with a 400 response code (possibly
+     with a text string such as "Connection closing due to lack of
+     security") and close the connection.  Otherwise, the server issues
+     a 382 response and TLS negotiation begins.  A server MUST NOT under
+     any circumstances reply to a STARTTLS command with either a 480 or
+     483 response.
+
+     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 authentication, the client might try to continue
+     the session in case the server allows it to do so even with no
+     authentication.  However, if TLS was being negotiated for
+     encryption, a client that gets a failure response needs to decide
+     whether to continue without TLS encryption, to wait and try again
+     later, or to give up and notify the user of the error.

       Upon receiving a 382 response to a STARTTLS command, the client
       MUST start the TLS negotiation before giving any other NNTP
@@ -229,34 +244,8 @@
       (otherwise it is not possible for a server with several hostnames
       to present the correct certificate to the client).

-     The server remains in the non-authenticated state, even if client
-     credentials are supplied during the TLS negotiation.  The AUTHINFO
-     SASL command [NNTP-AUTH] with the EXTERNAL mechanism [SASL] MAY be
-     used to authenticate once TLS client credentials are successfully
-     exchanged, but servers supporting the STARTTLS command are not
-     required to support AUTHINFO in general or that mechanism in
-     particular.  The server MAY use information from the client
-     certificate for identification of connections or posted articles
-     (either in its logs or directly in posted articles).
-
-     If the client receives a failure response to STARTTLS or if the TLS
-     negotiation fails, 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
-     authentication, the client might try to continue the session in
-     case the server allows it to do so even with no authentication.
-     However, if TLS was being negotiated for encryption, a client that
-     gets a failure response needs to decide whether to continue without
-     TLS encryption, to wait and try again later, or to give up and
-     notify the user of the error.
-
-     If the server is unable to initiate the TLS negotiation or if the
-     TLS negotiation fails, the server 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 security") and close the connection.
+     If the TLS negotiation fails, both client and server SHOULD
+     immediately close the connection.

       Upon successful completion of the TLS handshake, the NNTP protocol
       is reset to the state immediately after the initial greeting
@@ -271,6 +260,16 @@
       capability list, which was not obtained from the TLS negotiation
       itself.

+     The server remains in the non-authenticated state, even if client
+     credentials are supplied during the TLS negotiation.  The AUTHINFO
+     SASL command [NNTP-AUTH] with the EXTERNAL mechanism [SASL] MAY be
+     used to authenticate once TLS client credentials are successfully
+     exchanged, but servers supporting the STARTTLS command are not
+     required to support AUTHINFO in general or that mechanism in
+     particular.  The server MAY use information from the client
+     certificate for identification of connections or posted articles
+     (either in its logs or directly in posted articles).
+
       Both the client and the server MUST know if there is a TLS session
       active.  A client MUST NOT attempt to start a TLS session if a TLS
       session is already active.  A server MUST NOT return the STARTTLS
@@ -425,8 +424,8 @@
       does not mean that the entire NNTP chain has been made private.
       Furthermore, just because an NNTP server can authenticate an NNTP
       client, it does not mean that the articles from the NNTP client
-     were authenticated by the NNTP client when the client received
-     them.
+     were authenticated by the NNTP client when the client itself
+     received them (prior to forwarding them to the server).

       During the TLS negotiation, the client MUST check its understanding
       of the server hostname against the server's identity as presented
@@ -530,8 +529,9 @@

       o  Published Specification: This document.

-     o  Author, Change Controller, and Contact for Further Information:
-        Author of this document.
+     o  Contact for Further Information: Authors of this document.
+
+     o  Change Controller: IESG <[email-masked]>.

  7. References

@@ -544,7 +544,7 @@
       Requirement Levels", BCP 14, RFC 2119, March 1997.

       [NNTP] Feather, C., "Network News Transport Protocol",
-     draft-ietf-nntpext-base-*.txt, Work in Progress.
+     draft-ietf-nntpext-base-*, Work in Progress.

       [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0",
       RFC 2246, January 1999.
@@ -556,7 +556,7 @@
  7.2. Informative References

       [NNTP-AUTH] Vinocur, J., Murchison, K., Newman, C., "NNTP Extension
-     for Authentication", draft-ietf-nntpext-auth-*.txt, Work in
+     for Authentication", draft-ietf-nntpext-authinfo-*, Work in
       Progress.

       [SASL] Myers, J., "Simple Authentication and Security Layer
@@ -569,8 +569,8 @@

       Kenneth Murchison
       Oceana Matrix Ltd.
-     21 Princeton Place
-     Orchard Park, NY 14127 USA
+     2495 Main St, Suite 401
+     Buffalo, NY  14214

       Email: [email-masked]

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     2495 Main St. - Suite 401
716-604-0088 x26      Buffalo, NY 14214
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Russ Allbery <[email-masked]>
Date: Tue, 02 Aug 2005 09:02:01 -0700

> anything that I like.  Suggested text is welcome.

How about:

    While recovery may be theoretically possible, in practice TLS
    negotiation failure often leaves the session in an indeterminate
    state.

The other changes look good to me.

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

---

From: Ken Murchison <[email-masked]>
Date: Tue, 02 Aug 2005 12:15:44 -0400

>     negotiation failure often leaves the session in an indeterminate

OK, here's what I added:

"Note that while continuing the session is theoretically possible, in 
practice a TLS negotiation failure often leaves the session in an 
indeterminate state, therefore interoperability can not be guaranteed."

---

From: Russ Allbery <[email-masked]>
Date: Tue, 02 Aug 2005 09:27:46 -0700

> indeterminate state, therefore interoperability can not be guaranteed."

Looks good to me.