Subject: [NNTP] STARTTLS diffs

From: Ken Murchison <[email-masked]>
Date: Fri, 10 Jun 2005 12:39:16 -0400

Here's my rewrite of STARTTLS which hopefully addresses (or at least 
begins to address) all issues brought up during last call (especially 
those raised by Eric).  The most significant rewrites are in the 
Introduction (1), STARTTLS description (2.2.2) and Security 
Considerations (5).  Section 2.2.2.1 is been almost entirely removed 
because the client/server shouldn't be offering options that it isn't 
willing to accept, so checking them after the fact is really pointless. 
   Section 2.2.2.2 has been merged into 2.2.2.  I also added mandatory 
to implement cipher for interoperability (using the same one as RFC 
3501), and rewrote the text concerning verifying the hostname in the 
server's certificate.

If its too difficult to read the diffs, I have posted the entire 
document here:

ftp://ftp.oceana.com/pub/drafts/draft-ietf-nntpext-tls-nntp-07pre1.txt

--- starttls-6.txt	2005-06-10 12:06:40.000000000 -0400
+++ starttls-7.txt	2005-06-10 12:34:59.000000000 -0400
@@ -14,7 +14,7 @@

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

  Status of this memo
@@ -48,29 +48,39 @@
  Abstract

       This memo defines an extension to the Network News Transport
-     Protocol [NNTP] to provide connection-based security (via Transport
-     Layer Security [TLS]).  The primary goal is to provide encryption
+     Protocol (NNTP) to allow an NNTP client and server to use Transport
+     Layer Security (TLS).  The primary goal is to provide encryption
       for single-link confidentiality purposes, but data integrity,
       (optional) certificate-based peer entity authentication, and
       (optional) data compression are also possible.

+Note to the RFC Editor
+
+     The normative references to RFC 2234, RFC 2246, and RFC 3546 may
+     be replaced by draft-crocker-abnf-rfc2234bis,
+     draft-ietf-tls-rfc2246-bis, and draft-ietf-tls-rfc3526bis
+     respectively should any or all of those documents reach RFC status
+     before this one.
+
+     The normative reference to [NNTP] and the informative reference to
+     [NNTP-AUTH] are documents which are expected to be published
+     simultaneously with this one and so can be replaced by references
+     to the resulting RFCs.
+
  Table of Contents

-     0. Changes from Previous Version ............................  2
-     1. Introduction .............................................  3
+     1. Introduction .............................................  2
          1.1. Conventions Used in this Document ...................  3
       2. The STARTTLS Extension ...................................  3
          2.1. Advertising the STARTTLS Extension ..................  3
          2.2. STARTTLS Command ....................................  4
             2.2.1. Usage ..........................................  4
             2.2.2. Description ....................................  4
-              2.2.2.1. Processing After the STARTTLS Command .....  5
-              2.2.2.2. Result of the STARTTLS Command ............  6
-           2.2.3. Examples .......................................  7
+           2.2.3. Examples .......................................  6
       3. Augmented BNF Syntax for the STARTTLS Extension ..........  8
          3.1. Commands ............................................  8
-        3.2. Capability entries ..................................  9
-     4. Summary of Response Codes ................................  9
+        3.2. Capability entries ..................................  8
+     4. Summary of Response Codes ................................  8
       5. Security Considerations ..................................  9
       6. IANA Considerations ...................................... 11
       7. References ............................................... 12
@@ -79,40 +89,34 @@
       8. Authors' Addresses ....................................... 12
       9. Acknowledgments .......................................... 13
       10. Intellectual Property Rights ............................ 13
-     11. Copyright ............................................... 14
-
-0. Changes from Previous Version
-
-     Changed:
-     o  Made Ken the primary author.
-     o  Updated to RFC 3978/3979 boilerplate.
-     o  Fixed CAPABILITIES responses (specifically LIST arguments) in
-        examples.
-     o  Section 5: Consolidated two paragraphs to coincide with language
-        in [NNTP-AUTH].
-
-     Clarified:
-     o  Section 2.1: STARTTLS MUST NOT be advertised once a TLS layer
-        is active or after successful authentication.
-     o  Section 3: This document extends the ABNF in [NNTP], and the
-        [NNTP] ABNF must be imported first before validating the
-        STARTTLS ABNF (based on recommendations of AD regarding
-        IMAPEXT I-Ds).
+     11. Copyright ............................................... 13

  1. Introduction

       Historically, unencrypted NNTP [NNTP] connections were satisfactory
       for most purposes.  However, sending passwords unencrypted over the
-     network is no longer appropriate, and sometimes strong encryption
-     is desired for the entire connection.
+     network is no longer appropriate, and sometimes integrity and/or
+     confidentiality protection is desired for the entire connection.

-     The STARTTLS extension provides a way to use the popular TLS [TLS]
-     service with the existing NNTP protocol.  The current
-     (unstandardized) use of TLS for NNTP is most commonly on a
-     dedicated TCP port; this practice is discouraged for the reasons
-     documented in section 7 of "Using TLS with IMAP, POP3 and ACAP"
-     [TLS-IMAPPOP].  Therefore, this specification formalizes the
-     STARTTLS command already in occasional use by the installed base.
+     The TLS protocol (formerly known as SSL) provides a way to secure
+     an application protocol from tampering and eavesdropping.  Although
+     advanced SASL authentication mechanisms [NNTP-AUTH] can provide a
+     lightweight version of this service, TLS is complimentary to simple
+     authentication-only SASL mechanisms or deployed clear-text password
+     login commands.
+
+     In some existing implementations, TCP port 563 has been dedicated
+     to NNTP over TLS.  These implementations begin the TLS negotiation
+     immediately upon connection, and then continue with the initial
+     steps of an NNTP session.  This use of TLS on a separate port is
+     discouraged for the reasons documented in section 7 of "Using TLS
+     with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
+
+     This specification formalizes the STARTTLS command already in
+     occasional use by the installed base.  The STARTTLS command
+     rectifies a number of the problems with using a separate port for a
+     "secure" protocol variant, and is the preferred way of using TLS
+     with NNTP.

  1.1. Conventions Used in this Document

@@ -183,8 +187,8 @@

       A client issues the STARTTLS command to request negotiation of TLS.
       The STARTTLS command is usually used to initiate session security,
-     although it can be used for client certificate authentication
-     and/or data compression.
+     although it can also be used for client and/or server certificate
+     authentication and/or data compression.

       An NNTP server returns the 483 response to indicate that a secure
       or encrypted connection is required for the command sent by the
@@ -204,17 +208,7 @@
       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.
-
-     After receiving a 382 response to a STARTTLS command, the client
+     Upon receiving a 382 response to a STARTTLS command, the client
       MUST start the TLS negotiation before giving any other NNTP
       commands.  The TLS negotiation begins for both the client and
       server with the first octet following the CRLF of the 382 response.
@@ -233,56 +227,34 @@
       (otherwise it is not possible for a server with several hostnames
       to present the correct certificate to the client).

-     Although current use of TLS most often involves the dedication of
-     port 563 for NNTP over TLS, the continued use of TLS on a separate
-     port is discouraged for the reasons documented in section 7 of
-     "Using TLS with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
-
-2.2.2.1. Processing After the STARTTLS Command
-
-     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
-     without authentication and/or without 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.
-
-     If the NNTP client decides that the level of authentication or
-     privacy 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
-     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.
-
-     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 rules for the decisions are:
-
-     o  The client MAY check that the identity presented in the server's
-        certificate matches the intended server hostname or domain.
-        This check is not required (and may fail in the absence of the
-        TLS "server_name" extension [TLS-EXT], as described above), but
-        if it is implemented and the match fails, the client SHOULD
-        either request explicit user confirmation, or terminate the
-        connection but allow the user to disable the check in the
-        future.
-     o  Generally an NNTP server would want to accept any verifiable
-        certificate from a client, however authentication can be done
-        using the client certificate (perhaps in combination with the
-        SASL EXTERNAL mechanism [NNTP-AUTH], although an implementation
-        supporting STARTTLS is not required to support SASL in general
-        or that mechanism in particular).  The server MAY use
-        information about the client certificate for identification of
-        connections or posted articles (either in its logs or directly
-        in posted articles).
-
-2.2.2.2. Result of the STARTTLS Command
+     Generally an NNTP server would want to accept any verifiable
+     certificate from a client, however authentication can be done using
+     the client certificate (perhaps in combination with the SASL
+     EXTERNAL mechanism [NNTP-AUTH], although an implementation
+     supporting STARTTLS is not required to support SASL in general or
+     that mechanism in particular).  The server MAY use information
+     about 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.

       Upon successful completion of the TLS handshake, the NNTP protocol
       is reset to the state immediately after the initial greeting
@@ -308,11 +280,11 @@
       MUST NOT advertise the MODE-READER capability.

       The capability list returned in response to a CAPABILITIES command
-     received after the TLS handshake MAY be different than the list
-     returned before the TLS handshake.  For example, an NNTP server
-     supporting SASL [NNTP-AUTH] might not want to advertise support for
-     a particular mechanism unless a client has sent an appropriate
-     client certificate during a TLS handshake.
+     received after a successful TLS handshake MAY be different than the
+     list returned before the TLS handshake.  For example, an NNTP
+     server supporting SASL [NNTP-AUTH] might not want to advertise
+     support for a particular mechanism unless a client has sent an
+     appropriate client certificate during a TLS handshake.

  2.2.3. Examples

@@ -428,6 +400,13 @@
       described in section 12 of [NNTP]; those considerations remain
       relevant to any NNTP implementation.

+     NNTP client and server implementations MUST implement the
+     TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement
+     the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is
+     important as it assures that any two compliant implementations can
+     be configured to interoperate.  All other cipher suites are
+     OPTIONAL.
+
       Before the TLS handshake has begun, any protocol interactions are
       performed in the clear and may be modified by an active attacker.
       For this reason, clients and servers MUST discard any sensitive
@@ -437,39 +416,48 @@
       layer, and other protocol state SHOULD be re-negotiated as well.

       It should be noted that NNTP is not an end-to-end mechanism.  Thus,
-     if an NNTP client/server pair decide to add TLS privacy, they are
-     securing the transport only for that link.  Similarly, because
-     delivery of a single piece of news may go between more than two
-     NNTP servers, adding TLS privacy to one pair of servers does not
-     mean that the entire NNTP chain has been made private.
+     if an NNTP client/server pair decide to add TLS confidentiality,
+     they are securing the transport only for that link.  Similarly,
+     because delivery of a single piece of news may go between more than
+     two NNTP servers, adding TLS confidentiality to one pair of servers
+     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.

-     Both the NNTP client and server must check the result of the TLS
-     negotiation to see whether an acceptable degree of authentication
-     and privacy was achieved.  Ignoring this step completely
-     invalidates using TLS for security.  The decision about whether
-     acceptable authentication or privacy was achieved is made locally,
-     is implementation-dependent, and is beyond the scope of this
-     document.
-
-     The NNTP client and server should note carefully the result of the
-     TLS negotiation.  If the negotiation results in no privacy, or if
-     it results in privacy using algorithms or key lengths that are
-     deemed not strong enough, or if the authentication is not good
-     enough for either party, the client may choose to end the NNTP
-     session with an immediate QUIT command, or the server may choose
-     not to accept any more NNTP commands.
-
-     The client and server should also be aware that the TLS protocol
-     permits privacy and security capabilities to be renegotiated mid-
-     connection (see section 7.4.1 of [TLS]).  For example, one of the
-     parties may desire minimal encryption after any authentication
-     steps have been performed.  This underscores the fact that security
-     is not present simply because TLS has been negotiated; the nature
-     of the established security layer must be considered.
+     During the TLS negotiation, the client MUST check its understanding
+     of the server hostname against the server's identity as presented
+     in the server Certificate message, in order to prevent man-in-the-
+     middle attacks.  Matching is performed according to these rules:
+
+     -  The client MUST use the server hostname it used to open the
+        connection (or the hostname specified in TLS "server_name"
+        extension [TLS-EXT]) as the value to compare against the server
+        name as expressed in the server certificate.  The client MUST
+        NOT use any form of the server hostname derived from an insecure
+        remote source (e.g., insecure DNS lookup).  CNAME
+        canonicalization is not done.
+
+     -  If a subjectAltName extension of type dNSName is present in the
+        certificate, it SHOULD be used as the source of the server's
+        identity.
+
+     -  Matching is case-insensitive.
+
+     -  A "*" wildcard character MAY be used as the left-most name
+        component in the certificate.  For example, *.example.com would
+        match a.example.com, foo.example.com, etc. but would not match
+        example.com.
+
+     -  If the certificate contains multiple names (e.g. more than one
+        dNSName field), then a match with any one of the fields is
+        considered acceptable.
+
+
+     If the match fails, the client SHOULD either ask for explicit user
+     confirmation, or terminate the connection with a QUIT command and
+     indicate the server's identity is suspect.

       A man-in-the-middle attack can be launched by deleting the STARTTLS
       capability label in the CAPABILITIES response from the server.
@@ -483,12 +471,12 @@
       later session (of course, the STARTTLS capability would not be
       listed after a security layer is in place).

-     If the TLS negotiation fails or if the client receives a 483
+     If the TLS negotiation fails or if the client receives a 483 or 580
       response, the client has to decide what to do next.  The client has
       to choose among three main options:  to go ahead with the rest of
-     the NNTP session, to retry TLS later in the session, or to give up
-     and postpone newsreading/transport activity.  If a failure or error
-     occurs, the client can assume that the server may be able to
+     the NNTP session, to (re)try TLS later in the session, or to give
+     up and postpone newsreading/transport activity.  If a failure or
+     error occurs, the client can assume that the server may be able to
       negotiate TLS in the future, and should try to negotiate TLS in a
       later session.  However, if the client and server were only using
       TLS for authentication and no previous 480 response was received,
@@ -556,12 +544,12 @@
       [NNTP] Feather, C., "Network News Transport Protocol",
       draft-ietf-nntpext-base-*.txt, Work in Progress.

-     [TLS] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
-     draft-ietf-tls-rfc2246-bis-*.txt, Work in Progress.
+     [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0",
+     RFC 2246, January 1999.

       [TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
       Mikkelsen, J., Wright, T., "Transport Layer Security (TLS)
-     Extensions", draft-ietf-tls-rfc3546bis-*.txt, Work in Progress.
+     Extensions", RFC 3546, June 2003.

  7.2. Informative References

@@ -596,12 +584,12 @@
       1050 Lakes Drive, Suite 250
       West Covina, CA  91790

-     EMail: [email-masked]
+     EMail: [email-masked]

  9. Acknowledgments

-     A significant amount of the STARTTLS text was lifted from RFC 3207
-     by Paul Hoffman.
+     A significant amount of the text in this document was lifted from
+     RFC 2595 by Chris Newman and RFC 3207 by Paul Hoffman.

       Special acknowledgment goes also to the people who commented
       privately on intermediate revisions of this document, as well as

-- 
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: "Jeffrey M. Vinocur" <[email-masked]>
Date: Sat, 11 Jun 2005 14:51:25 -0400

> +     confidentiality protection is desired for the entire connection.

"are desired"?  I'm not sure how to conjugate with an "and/or" but the 
"is" looks funny to me.

> -     service with the existing NNTP protocol.  [...]

I really like what you did with this paragraph.

> +     [...] TLS is complimentary to simple

         TLS is complimentary to both simple, authentication-only SASL
         mechanisms, and widely-deployed clear-text password 
authentication.

?

> +     middle attacks.

This is stronger than we had before, and I think I like it.  My only 
hesitation is, I think the user should have the ability to turn off the 
hostname checking (for the case in which he does not expect it to 
match, since that's fairly common at present).

For that to happen, do we have to do something like "the client MUST 
have the ability to check...and this MUST be the default 
configuration"?

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: Ken Murchison <[email-masked]>
Date: Sun, 12 Jun 2005 18:27:42 -0400

> "are desired"?  I'm not sure how to conjugate with an "and/or" but the 

I'm not sure which is more appropriate.  I think arguments can be made 
for both.  Any other opinions?

>         mechanisms, and widely-deployed clear-text password authentication.
> 
> ?

Sure.

> hostname checking (for the case in which he does not expect it to match, 
> since that's fairly common at present).
> 
> have the ability to check...and this MUST be the default configuration"?

Hmm, not sure.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 13 Jun 2005 01:47:18 -0700

> I'm not sure which is more appropriate.  I think arguments can be made for
> both.  Any other opinions?

It's one of those areas of English where either seems to be used.  I think
it's fine.

> Hmm, not sure.

I think we have it covered.  I like the current wording.  It says one MUST
check but then SHOULD do something about the results of the check, which
provides an out for local configuration (and then one might not check
under an as-if rule, but that's not our business).  This text errs on the
side of security, which is what we should do.

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

---

From: Russ Allbery <[email-masked]>
Date: Mon, 13 Jun 2005 01:47:41 -0700

Ken Murchison <[email-masked]> writes:

> those raised by Eric).

This one looks good to me as well.

---

From: EKR <[email-masked]>
Date: Tue, 14 Jun 2005 09:14:31 -0700

> +     indicate the server's identity is suspect.

In some sense this is fine, as it embodies the RFC 2818 model of the
universe. However, it doesn't really match up so well with a 
self-signed cert model, in which it doesn't really matter what
the DN is, b/c you're trusting it explicitly anyway... I mean,
you *can* check the domain name, but why bother....

I'm not sure what model you expect people to be using...

-Ekr

---

From: Ken Murchison <[email-masked]>
Date: Tue, 14 Jun 2005 16:50:08 -0400

> I'm not sure what model you expect people to be using...

I'm expecting the NNTP STARTTLS implementation to be as close as 
possible to IMAP, POP3 and SMTP.  All three of these specs have similar 
wording.  In fact, I took this wording from either RFC 3501 or RFC 2595. 
  Is there something different about NNTP that makes the above text 
silly/useless or are you saying that its silly/useless for all of the 
messaging protocols?

Would you completely remove the above text from the NNTP STARTTLS document?

---

From: Russ Allbery <[email-masked]>
Date: Sat, 25 Jun 2005 12:00:00 -0700

>> universe. However, it doesn't really match up so well with a self-signed
>> cert model, in which it doesn't really matter what

> wording.  In fact, I took this wording from either RFC 3501 or RFC
> 2595. Is there something different about NNTP that makes the above text

> Would you completely remove the above text from the NNTP STARTTLS

After reviewing this, I think Ken's text makes sense for NNTP.  Currently,
most of the NNTP clients that do TLS are reusing the same code from a mail
component that also does TLS, and I know from experience that they do
verify certificates, including self-signed ones.  I'm not sure that we're
realistically going to have a choice about the cert verification model;
vendors are going to strongly tend towards reusing the cert verification
model they're already using for other protocols, which does the domain
name checking.

As you mention, for self-signed certificates it doesn't really matter
whether you check it or not -- it's not difficult to get the domain name
correct in the certificate.  Since for certain other trust models, it
*does* matter, I would rather just require that clients check.

Ken, could you go ahead and submit the revised draft for publication as an
I-D?  Eric, if you object given the above, please do let us know; I don't
mean to cut off discussion, but since my guess is that we won't need to
change this text, I'd rather get the revised draft into the queue so that
we don't have to worry about it later.

Our current intention is to declare things done by the middle of July to
hit the next IESG review after our AD's vacation.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 25 Jun 2005 19:19:22 -0700

> we don't have to worry about it later.
This seems fine to me. Someone needs to write a "how to use self-signed
certs" doc, but I haven't gotten to it yet... :)

-Ekr