< draft-elie-nntp-tls-recommendations-04.txt		draft-elie-nntp-tls-recommendations-05.txt >
	Independent Submission J. Elie		Independent Submission J. Elie
	Internet-Draft January 5, 2017		Internet-Draft February 7, 2017
	Updates: 4642 (if approved)		Updates: 4642 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: July 9, 2017		Expires: August 11, 2017
	Use of Transport Layer Security (TLS)		Use of Transport Layer Security (TLS)
	in the Network News Transfer Protocol (NNTP)		in the Network News Transfer Protocol (NNTP)
	draft-elie-nntp-tls-recommendations-04		draft-elie-nntp-tls-recommendations-05
	Abstract		Abstract
	This document provides recommendations for improving the security of		This document provides recommendations for improving the security of
	the Network News Transfer Protocol (NNTP) when using Transport Layer		the Network News Transfer Protocol (NNTP) when using Transport Layer
	Security (TLS). It modernizes the NNTP usage of TLS to be consistent		Security (TLS). It modernizes the NNTP usage of TLS to be consistent
	with TLS best current practices. If approved, this document updates		with TLS best current practices. If approved, this document updates
	RFC 4642.		RFC 4642.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 9, 2017.		This Internet-Draft will expire on August 11, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	Appendix A. Detailed Changes to RFC 4642 . . . . . . . . . . . . 11		Appendix A. Detailed Changes to RFC 4642 . . . . . . . . . . . . 11
	A.1. Related to TLS-level Compression . . . . . . . . . . . . 11		A.1. Related to TLS-level Compression . . . . . . . . . . . . 11
	A.2. Related to Implicit TLS . . . . . . . . . . . . . . . . . 11		A.2. Related to Implicit TLS . . . . . . . . . . . . . . . . . 11
	A.3. Related to RC4 Cipher Suites . . . . . . . . . . . . . . 12		A.3. Related to RC4 Cipher Suites . . . . . . . . . . . . . . 12
	A.4. Related to Server Name Indication . . . . . . . . . . . . 12		A.4. Related to Server Name Indication . . . . . . . . . . . . 12
	A.5. Related to Certificate Verification . . . . . . . . . . . 12		A.5. Related to Certificate Verification . . . . . . . . . . . 12
	A.6. Related to Other Obsolete Wording . . . . . . . . . . . . 13		A.6. Related to Other Obsolete Wording . . . . . . . . . . . . 13
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 13		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 13
	Appendix C. Document History (to be removed by RFC Editor before		Appendix C. Document History (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 13		publication) . . . . . . . . . . . . . . . . . . . . 13
	C.1. Changes since -03 . . . . . . . . . . . . . . . . . . . . 13		C.1. Changes since -04 . . . . . . . . . . . . . . . . . . . . 13
	C.2. Changes since -02 . . . . . . . . . . . . . . . . . . . . 13		C.2. Changes since -03 . . . . . . . . . . . . . . . . . . . . 14
	C.3. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14		C.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 14
	C.4. Changes since -00 . . . . . . . . . . . . . . . . . . . . 15		C.4. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14
			C.5. Changes since -00 . . . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Network News Transfer Protocol (NNTP) [RFC3977] has been using		The Network News Transfer Protocol (NNTP) [RFC3977] has been using
	Transport Layer Security (TLS) [RFC5246] (along with its precursor,		Transport Layer Security (TLS) [RFC5246] (along with its precursor,
	Secure Sockets Layer or SSL) since at least year 2000. The use of		Secure Sockets Layer or SSL) since at least year 2000. The use of
	TLS in NNTP was formalized in [RFC4642], providing at the same time		TLS in NNTP was formalized in [RFC4642], providing at the same time
	implementation recommendations. In order to address the evolving		implementation recommendations. In order to address the evolving
	threat model on the Internet today, this document provides stronger		threat model on the Internet today, this document provides stronger
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	and DTLS" [RFC7525]. This includes stronger recommendations		and DTLS" [RFC7525]. This includes stronger recommendations
	regarding SSL/TLS protocol versions, fallback to lower versions, TLS		regarding SSL/TLS protocol versions, fallback to lower versions, TLS
	negotiation, TLS-level compression, TLS session resumption, cipher		negotiation, TLS-level compression, TLS session resumption, cipher
	suites, public key lengths, forward secrecy, hostname validation,		suites, public key lengths, forward secrecy, hostname validation,
	certificate verification, and other aspects of using TLS with NNTP.		certificate verification, and other aspects of using TLS with NNTP.
	[[Q1: For RFC Editor: Throughout the document, should [RFC7525] be		[[Q1: For RFC Editor: Throughout the document, should [RFC7525] be
	referenced as [BCP195] or [RFC7525]? Same question for other BCP		referenced as [BCP195] or [RFC7525]? Same question for other BCP
	documents.]]		documents.]]
	[[Q2: For RFC Editor: Throughout the document, the references to
	[MUA-STS] (draft-ietf-uta-email-deep) and [NNTP-COMPRESS] (draft-
	murchison-nntp-compress) should be referenced as their equivalent
	[RFCxxxx], once published.]]
	1.1. Conventions Used in This Document		1.1. Conventions Used in This Document
	Any term not defined in this document has the same meaning as it does		Any term not defined in this document has the same meaning as it does
	in [RFC4642] or the NNTP core specification [RFC3977].		in [RFC4642] or the NNTP core specification [RFC3977].
	When this document uses the terms "implicit TLS", it refers to TLS		When this document uses the terms "implicit TLS", it refers to TLS
	negotiation immediately upon connection on a separate port.		negotiation immediately upon connection on a separate port.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 6 ¶
	compression (Section 3.3 of [RFC7525]), thus no longer using TLS		compression (Section 3.3 of [RFC7525]), thus no longer using TLS
	as a means to provide data compression (contrary to Abstract and		as a means to provide data compression (contrary to Abstract and
	Section 2.2.2 of [RFC4642]).		Section 2.2.2 of [RFC4642]).
	o NNTP implementations and deployments SHOULD prefer implicit TLS		o NNTP implementations and deployments SHOULD prefer implicit TLS
	and therefore use strict TLS configuration (Section 3.2 of		and therefore use strict TLS configuration (Section 3.2 of
	[RFC7525]), that is to say they SHOULD use a port dedicated to		[RFC7525]), that is to say they SHOULD use a port dedicated to
	NNTP over TLS, and begin the TLS negotiation immediately upon		NNTP over TLS, and begin the TLS negotiation immediately upon
	connection (contrary to a dynamic upgrade from unencrypted to TLS-		connection (contrary to a dynamic upgrade from unencrypted to TLS-
	protected traffic via the use of the STARTTLS command, as		protected traffic via the use of the STARTTLS command, as
	Section 1 of [RFC4642] was encouraging). For the same reasons,		Section 1 of [RFC4642] was encouraging). Implicit TLS is the
	transposed to NNTP, as those given in Appendix A of [MUA-STS]		preferred way of using TLS with NNTP for the same reasons,
	(whose one of the authors was also one of the authors of		transposed to NNTP, as those given in Appendix A of [MUA-STS].
	[RFC4642]), implicit TLS is the preferred way of using TLS with		(Note that [MUA-STS] and [RFC4642] have one author in common.)
	NNTP.
	o NNTP implementations and deployments MUST NOT negotiate RC4 cipher		o NNTP implementations and deployments MUST NOT negotiate RC4 cipher
	suites ([RFC7465]) contrary to Section 5 of [RFC4642] that		suites ([RFC7465]) contrary to Section 5 of [RFC4642] that
	REQUIRED them to implement the TLS_RSA_WITH_RC4_128_MD5 cipher		required them to implement the TLS_RSA_WITH_RC4_128_MD5 cipher
	suite so as to ensure that any two NNTP compliant implementations		suite so as to ensure that any two NNTP compliant implementations
	can be configured to interoperate. This document removes that		can be configured to interoperate. This document removes that
	requirement, so that NNTP client and server implementations follow		requirement, so that NNTP client and server implementations follow
	the recommendations given in Sections 4.2 and 4.2.1 of [RFC7525]		the recommendations given in Sections 4.2 and 4.2.1 of [RFC7525]
	instead. The mandatory-to-implement cipher(s) suite(s) depend on		instead. The mandatory-to-implement cipher(s) suite(s) depend on
	the TLS protocol version. For instance, when TLS 1.2 is used, the		the TLS protocol version. For instance, when TLS 1.2 is used, the
	TLS_RSA_WITH_AES_128_CBC_SHA cipher suite MUST be implemented		TLS_RSA_WITH_AES_128_CBC_SHA cipher suite MUST be implemented
	(Section 9 of [RFC5246]).		(Section 9 of [RFC5246]).
	o NNTP implementations and deployments MUST support the Server Name		o All NNTP clients and any NNTP server that is known by multiple
	Indication (SNI) extension defined in Section 3 of [RFC6066],		names MUST support the Server Name Indication (SNI) extension
	contrary to Section 2.2.2 of [RFC4642] for which it was only a		defined in Section 3 of [RFC6066], in conformance with Section 3.6
	SHOULD. All clients and servers known by multiple names MUST		of [RFC7525]. It was only a "SHOULD" in Section 2.2.2 of
	support the SNI extension, in conformance with Section 3.6 of		[RFC4642].
	[RFC7525].
	o NNTP implementations and deployments MUST follow the rules and		o NNTP implementations and deployments MUST follow the rules and
	guidelines defined in [RFC6125] and [RFC5280] for hostname		guidelines defined in [RFC6125] and [RFC5280] for hostname
	validation and certificate verification. Part of Section 5 of		validation and certificate verification. Part of Section 5 of
	[RFC4642] is therefore rationalized in favour of following those		[RFC4642] is therefore rationalized in favour of following those
	two documents.		two documents.
	Appendix A of this document gives detailed changes with regards to		Appendix A of this document gives detailed changes with regards to
	the wording of [RFC4642].		the wording of [RFC4642].
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 8 ¶
	Therefore, NNTP implementations and deployments compliant with this		Therefore, NNTP implementations and deployments compliant with this
	document are REQUIRED to also comply with [RFC7525].		document are REQUIRED to also comply with [RFC7525].
	Instead of repeating those recommendations here, this document mostly		Instead of repeating those recommendations here, this document mostly
	provides supplementary information regarding secure implementation		provides supplementary information regarding secure implementation
	and deployment of NNTP technologies.		and deployment of NNTP technologies.
	3.1. Compression		3.1. Compression
	NNTP supports the use of the COMPRESS command, defined in Section 2.2		NNTP supports the use of the COMPRESS command, defined in Section 2.2
	of [NNTP-COMPRESS], to compress data between an NNTP client and		of [RFC8054], to compress data between an NNTP client and server.
	server. Although this NNTP extension might have slightly stronger		Although this NNTP extension might have slightly stronger security
	security properties than TLS-level compression [RFC3749] (since NNTP		properties than TLS-level compression [RFC3749] (since NNTP
	compression can be activated after authentication has completed, thus		compression can be activated after authentication has completed, thus
	reducing the chances that authentication credentials can be leaked		reducing the chances that authentication credentials can be leaked
	via for instance a CRIME attack, as described in Section 2.6 of		via for instance a Compression Ratio Info-leak Made Easy (CRIME)
	[CRIME]), this document neither encourages nor discourages the use of		attack, as described in Section 2.6 of [CRIME]), this document
	the NNTP COMPRESS extension.		neither encourages nor discourages the use of the NNTP COMPRESS
			extension.
	3.2. Protocol Versions and Security Preferences		3.2. Protocol Versions and Security Preferences
	NNTP implementations of news servers are encouraged to support		NNTP implementations of news servers are encouraged to support
	options to configure the minimal TLS protocol version to accept, and		options to configure the minimal TLS protocol version to accept, and
	which cipher suites, signature algorithms or groups (like elliptic		which cipher suites, signature algorithms or groups (like elliptic
	curves) to use for incoming connections. Additional options can		curves) to use for incoming connections. Additional options can
	naturally also be supported. The goal is to enable administrators of		naturally also be supported. The goal is to enable administrators of
	news servers to easily and quickly strengthen security, if need be		news servers to easily and quickly strengthen security, if need be
	(for instance by rejecting cipher suites considered unsafe with		(for instance by rejecting cipher suites considered unsafe with
	skipping to change at page 5, line 46 ¶		skipping to change at page 5, line 43 ¶
	The TLS extension for Server Name Indication (SNI) defined in		The TLS extension for Server Name Indication (SNI) defined in
	Section 3 of [RFC6066] MUST be implemented by all news clients. It		Section 3 of [RFC6066] MUST be implemented by all news clients. It
	also MUST be implemented by any news server that is known by multiple		also MUST be implemented by any news server that is known by multiple
	names. (Otherwise, it is not possible for a server with several		names. (Otherwise, it is not possible for a server with several
	hostnames to present the correct certificate to the client.)		hostnames to present the correct certificate to the client.)
	3.4. Prevention of SSL Stripping		3.4. Prevention of SSL Stripping
	In order to help prevent SSL Stripping attacks (Section 2.1 of		In order to help prevent SSL Stripping attacks (Section 2.1 of
	[RFC7457]), NNTP implementations and deployments are encouraged to		[RFC7457]), NNTP implementations and deployments MUST follow the
	follow the recommendations provided in Section 3.2 of [RFC7525].		recommendations provided in Section 3.2 of [RFC7525]. Notably, in
	Notably, in case implicit TLS is not used, news clients SHOULD		case implicit TLS is not used, news clients SHOULD attempt to
	attempt to negotiate TLS even if the server does not advertise the		negotiate TLS even if the server does not advertise the STARTTLS
	STARTTLS capability label in response to the CAPABILITIES command		capability label in response to the CAPABILITIES command (Section 2.1
	(Section 2.1 of [RFC4642]).		of [RFC4642]).
	3.5. Authenticated Connections		3.5. Authenticated Connections
	[RFC4642] already provides recommendations and requirements for		[RFC4642] already provides recommendations and requirements for
	certificate validation in the context of checking the client or the		certificate validation in the context of checking the client or the
	server's identity. Those requirements are strengthened by		server's identity. Those requirements are strengthened by
	Appendix A.5 of this document.		Appendix A.5 of this document.
	Wherever possible, it is best to prefer certificate-based		Wherever possible, it is best to prefer certificate-based
	authentication (along with SASL [RFC4422]), and ensure that:		authentication (along with SASL [RFC4422]), and ensure that:
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	This document does not mandate certificate-based authentication,		This document does not mandate certificate-based authentication,
	although such authentication is strongly preferred. As mentioned in		although such authentication is strongly preferred. As mentioned in
	Section 2.2.2 of [RFC4642], the AUTHINFO SASL command (Section 2.4 of		Section 2.2.2 of [RFC4642], the AUTHINFO SASL command (Section 2.4 of
	[RFC4643]) with the EXTERNAL mechanism (Appendix A of [RFC4422]) MAY		[RFC4643]) with the EXTERNAL mechanism (Appendix A of [RFC4422]) MAY
	be used to authenticate a client once its TLS credentials have been		be used to authenticate a client once its TLS credentials have been
	successfully exchanged.		successfully exchanged.
	Given the pervasiveness of eavesdropping [RFC7258], even an encrypted		Given the pervasiveness of eavesdropping [RFC7258], even an encrypted
	but unauthenticated connection might be better than an unencrypted		but unauthenticated connection might be better than an unencrypted
	connection (this is similar to the "better-than-nothing security"		connection (this is similar to the "better-than-nothing security"
	approach for IPsec [RFC5386]). Encrypted but unauthenticated		approach for IPsec [RFC5386], and in accordance with opportunistic
			security principles [RFC7435]). Encrypted but unauthenticated
	connections include connections negotiated using anonymous		connections include connections negotiated using anonymous
	Diffie-Hellman mechanisms or using self-signed certificates, among		Diffie-Hellman mechanisms or using self-signed certificates, among
	others.		others.
	Note: when an NNTP server receives a Netnews article, it MAY add a		Note: when an NNTP server receives a Netnews article, it MAY add a
	<diag-match> (Section 3.1.5 of [RFC5536]), which appears as "!!" in		<diag-match> (Section 3.1.5 of [RFC5536]), which appears as "!!" in
	the Path header field of that article, to indicate that it verified		the Path header field of that article, to indicate that it verified
	the identity of the client or peer server. This document encourages		the identity of the client or peer server. This document encourages
	the construction of such Path header fields, as described in		the construction of such Path header fields, as described in
	Section 3.2.1 of [RFC5537].		Section 3.2.1 of [RFC5537].
	3.6. Human Factors		3.6. Human Factors
	It is strongly encouraged that NNTP clients provide ways for end		NNTP clients SHOULD provide ways for end users (and NNTP servers
	users (and that NNTP servers provide ways for administrators) to		SHOULD provide ways for administrators) to complete at least the
	complete at least the following tasks:		following tasks:
	o Determine if a given incoming or outgoing connection is encrypted		o Determine if a given incoming or outgoing connection is encrypted
	using a security layer (either using TLS or an SASL mechanism that		using a security layer (either using TLS or an SASL mechanism that
	negotiates a security layer).		negotiates a security layer).
	o Determine the version of TLS used for encryption of a given		o Be warned if the version of TLS used for encryption of a given
	stream.		stream is not secure enough.
	o If authenticated encryption is used, determine how the connection		o If authenticated encryption is used, determine how the connection
	was authenticated or verified.		was authenticated or verified.
	o Inspect the certificate offered by an NNTP server.		o Be warned if the certificate offered by an NNTP server cannot be
			verified.
	o Determine the cipher suite used to encrypt a connection.		o Be warned if the cipher suite used to encrypt a connection is not
			secure enough.
	o Be warned if the certificate changes for a given server.		o Be warned if the certificate changes for a given server.
	o When a security layer is not already in place, be warned if a		o When a security layer is not already in place, be warned if a
	given server stops advertising the STARTTLS capability label in		given server stops advertising the STARTTLS capability label in
	response to the CAPABILITIES command (Section 2.1 of [RFC4642])		response to the CAPABILITIES command (Section 2.1 of [RFC4642])
	whereas it advertised the STARTTLS capability label during any		whereas it advertised the STARTTLS capability label during any
	previous connection within a (possibly configurable) time frame.		previous connection within a (possibly configurable) time frame.
	(Otherwise, a human might not see the warning the first time, and		(Otherwise, a human might not see the warning the first time, and
	the warning would disappear immediately after that.)		the warning would disappear immediately after that.)
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 38 ¶
	received from the server whereas the STARTTLS capability label was		received from the server whereas the STARTTLS capability label was
	advertised.		advertised.
	Note that the last two tasks cannot occur when implicit TLS is used,		Note that the last two tasks cannot occur when implicit TLS is used,
	and that the penultimate task helps prevent an attack known as SSL		and that the penultimate task helps prevent an attack known as SSL
	Stripping (Section 2.1 of [RFC7457]).		Stripping (Section 2.1 of [RFC7457]).
	4. Security Considerations		4. Security Considerations
	Beyond the security considerations already described in [RFC4642],		Beyond the security considerations already described in [RFC4642],
	[RFC6125] and [RFC7525], the author wishes to add the following		[RFC6125] and [RFC7525], the following caveat is worth mentioning
	caveat when not using implicit TLS.		when not using implicit TLS: NNTP servers need to ensure that they
			are not vulnerable to the STARTTLS command injection vulnerability
	NNTP servers need ensure that they are not vulnerable to the STARTTLS		(Section 2.2 of [RFC7457]). Though this command MUST NOT be
	command injection vulnerability (Section 2.2 of [RFC7457]). Though		pipelined, an attacker could pipeline it. Therefore, NNTP servers
	this command MUST NOT be pipelined, an attacker could pipeline it.		MUST discard any NNTP command received between the use of STARTTLS
	Therefore, NNTP servers MUST discard any NNTP command received		and the end of TLS negotiation.
	between the use of STARTTLS and the end of TLS negotiation.
	5. IANA Considerations		5. IANA Considerations
	This document does not change the formal definition of the STARTTLS		This document does not change the formal definition of the STARTTLS
	extension (Section 6 of [RFC4642]). Nonetheless, as implementations		extension (Section 6 of [RFC4642]). Nonetheless, as implementations
	of the STARTTLS extension should follow this document, IANA will add		of the STARTTLS extension should follow this document, IANA will add
	its reference to the existing STARTTLS label in the NNTP capability		its reference to the existing STARTTLS label in the NNTP capability
	labels registry contained in the Network News Transfer Protocol		labels registry contained in the Network News Transfer Protocol
	(NNTP) Parameters registry:		(NNTP) Parameters registry:
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 26 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",		[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
	RFC 3977, DOI 10.17487/RFC3977, October 2006,		RFC 3977, DOI 10.17487/RFC3977, October 2006,
	<http://www.rfc-editor.org/info/rfc3977>.		<http://www.rfc-editor.org/info/rfc3977>.
			[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
			Authentication and Security Layer (SASL)", RFC 4422,
			DOI 10.17487/RFC4422, June 2006,
			<http://www.rfc-editor.org/info/rfc4422>.
	[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using		[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using
	Transport Layer Security (TLS) with Network News Transfer		Transport Layer Security (TLS) with Network News Transfer
	Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October		Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October
	2006, <http://www.rfc-editor.org/info/rfc4642>.		2006, <http://www.rfc-editor.org/info/rfc4642>.
			[RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer
			Protocol (NNTP) Extension for Authentication", RFC 4643,
			DOI 10.17487/RFC4643, October 2006,
			<http://www.rfc-editor.org/info/rfc4643>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<http://www.rfc-editor.org/info/rfc5246>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.		<http://www.rfc-editor.org/info/rfc5280>.
			[RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
			Article Format", RFC 5536, DOI 10.17487/RFC5536, November
			2009, <http://www.rfc-editor.org/info/rfc5536>.
			[RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and
			Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009,
			<http://www.rfc-editor.org/info/rfc5537>.
	[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)		[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
	Extensions: Extension Definitions", RFC 6066,		Extensions: Extension Definitions", RFC 6066,
	DOI 10.17487/RFC6066, January 2011,		DOI 10.17487/RFC6066, January 2011,
	<http://www.rfc-editor.org/info/rfc6066>.		<http://www.rfc-editor.org/info/rfc6066>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March		Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	skipping to change at page 9, line 17 ¶		skipping to change at page 9, line 37 ¶
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <http://www.rfc-editor.org/info/rfc7525>.		2015, <http://www.rfc-editor.org/info/rfc7525>.
	6.2. Informative References		6.2. Informative References
	[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty		[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty
	Security Conference, 2012.		Security Conference, 2012.
	[MUA-STS] Moore, K. and C. Newman, "Mail User Agent Strict Transport		[MUA-STS] Moore, K. and C. Newman, "Mail User Agent Strict Transport
	Security (MUA-STS)", July 2016.		Security (MUA-STS)", Work in Progress, July 2016.
	[NNTP-COMPRESS]
	Murchison, K. and J. Elie, "Network News Transfer Protocol
	(NNTP) Extension for Compression", October 2016.
	[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol		[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
	Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May		Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May
	2004, <http://www.rfc-editor.org/info/rfc3749>.		2004, <http://www.rfc-editor.org/info/rfc3749>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <http://www.rfc-editor.org/info/rfc4301>.		December 2005, <http://www.rfc-editor.org/info/rfc4301>.
	[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
	Authentication and Security Layer (SASL)", RFC 4422,
	DOI 10.17487/RFC4422, June 2006,
	<http://www.rfc-editor.org/info/rfc4422>.
	[RFC4643] Vinocur, J. and K. Murchison, "Network News Transfer
	Protocol (NNTP) Extension for Authentication", RFC 4643,
	DOI 10.17487/RFC4643, October 2006,
	<http://www.rfc-editor.org/info/rfc4643>.
	[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing		[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
	Security: An Unauthenticated Mode of IPsec", RFC 5386,		Security: An Unauthenticated Mode of IPsec", RFC 5386,
	DOI 10.17487/RFC5386, November 2008,		DOI 10.17487/RFC5386, November 2008,
	<http://www.rfc-editor.org/info/rfc5386>.		<http://www.rfc-editor.org/info/rfc5386>.
	[RFC5536] Murchison, K., Ed., Lindsey, C., and D. Kohn, "Netnews
	Article Format", RFC 5536, DOI 10.17487/RFC5536, November
	2009, <http://www.rfc-editor.org/info/rfc5536>.
	[RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture and
	Protocols", RFC 5537, DOI 10.17487/RFC5537, November 2009,
	<http://www.rfc-editor.org/info/rfc5537>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <http://www.rfc-editor.org/info/rfc7258>.		2014, <http://www.rfc-editor.org/info/rfc7258>.
			[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
			Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
			December 2014, <http://www.rfc-editor.org/info/rfc7435>.
	[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing		[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
	Known Attacks on Transport Layer Security (TLS) and		Known Attacks on Transport Layer Security (TLS) and
	Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,		Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
	February 2015, <http://www.rfc-editor.org/info/rfc7457>.		February 2015, <http://www.rfc-editor.org/info/rfc7457>.
	[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,		[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
	DOI 10.17487/RFC7465, February 2015,		DOI 10.17487/RFC7465, February 2015,
	<http://www.rfc-editor.org/info/rfc7465>.		<http://www.rfc-editor.org/info/rfc7465>.
	[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer		[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer
	Security (TLS) in the Extensible Messaging and Presence		Security (TLS) in the Extensible Messaging and Presence
	Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June		Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June
	2015, <http://www.rfc-editor.org/info/rfc7590>.		2015, <http://www.rfc-editor.org/info/rfc7590>.
			[RFC8054] Murchison, K. and J. Elie, "Network News Transfer Protocol
			(NNTP) Extension for Compression", RFC 8054,
			DOI 10.17487/RFC8054, January 2017,
			<http://www.rfc-editor.org/info/rfc8054>.
	Appendix A. Detailed Changes to RFC 4642		Appendix A. Detailed Changes to RFC 4642
	This section lists detailed changes this document applies to		This section lists detailed changes this document applies to
	[RFC4642].		[RFC4642].
	A.1. Related to TLS-level Compression		A.1. Related to TLS-level Compression
	The second sentence in the Abstract of [RFC4642] is replaced with the		The second sentence in the Abstract of [RFC4642] is replaced with the
	following text:		following text:
	skipping to change at page 13, line 24 ¶		skipping to change at page 13, line 24 ¶
	of [RFC5246] apply.		of [RFC5246] apply.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	This document draws heavily on ideas in [RFC7590] by Peter		This document draws heavily on ideas in [RFC7590] by Peter
	Saint-Andre and Thijs Alkemade; a large portion of this text was		Saint-Andre and Thijs Alkemade; a large portion of this text was
	borrowed from that specification.		borrowed from that specification.
	The author would like to thank the following individuals for		The author would like to thank the following individuals for
	contributing their ideas and support for writing this specification:		contributing their ideas and support for writing this specification:
	Michael Baeuerle, Stephane Bortzmeyer, Viktor Dukhovni, Sabahattin		Stephane Bortzmeyer, Ben Campbell, Viktor Dukhovni, Stephen Farrell,
	Gucukoglu, Richard Kettlewell, Jouni Korhonen, David Eric Mandelberg,		Sabahattin Gucukoglu, Richard Kettlewell, Jouni Korhonen, Mirja
	Matija Nalis, Chris Newman, and Peter Saint-Andre.		Kuehlewind, David Eric Mandelberg, Matija Nalis, Chris Newman, and
			Peter Saint-Andre.
	Many thanks to the Responsible Area Director, Alexey Melnikov, for		Special thanks to Michael Baeuerle, for shepherding this document,
	reviewing and sponsoring this document.		and to the Responsible Area Director, Alexey Melnikov, for sponsoring
			it. They both significantly helped to increase its quality.
	Appendix C. Document History (to be removed by RFC Editor before		Appendix C. Document History (to be removed by RFC Editor before
	publication)		publication)
	C.1. Changes since -03		C.1. Changes since -04
			o Take into account the remarks received during IESG telechat.
			o Mention the Document Shepherd, Michael Baeuerle.
			o Update the reference [NNTP-COMPRESS] to [RFC8054], now it has been
			released.
			o Add a reference to [RFC7435].
			o Move [RFC4422], [RFC4643], [RFC5536], and [RFC5537] from
			informative to normative references.
			o A few wording improvements.
			C.2. Changes since -03
	o Improve wording to make clear that the server hostname that the		o Improve wording to make clear that the server hostname that the
	client used to open the connection is the same as the one		client used to open the connection is the same as the one
	specified in the TLS "server_name" extension.		specified in the TLS "server_name" extension.
	o Move [RFC5280], [RFC6125] and [RFC7525] to normative references.		o Move [RFC5280], [RFC6125] and [RFC7525] to normative references.
	o In detailed changes of [RFC4642], use [NNTP] instead of [RFC3977]		o In detailed changes of [RFC4642], use [NNTP] instead of [RFC3977]
	as this RFC is referenced as [NNTP] in [RFC4642]. Also mention		as this RFC is referenced as [NNTP] in [RFC4642]. Also mention
	obsolete [PKI-CERT].		obsolete [PKI-CERT].
	C.2. Changes since -02		C.3. Changes since -02
	o Use (and define) the "implicit TLS" terminology instead of "strict		o Use (and define) the "implicit TLS" terminology instead of "strict
	TLS". The language in [RFC7525] is unfortunate since "strict TLS"		TLS". The language in [RFC7525] is unfortunate since "strict TLS"
	is not clearly defined in that document, and the name suggests		is not clearly defined in that document, and the name suggests
	that it is an alternative to "opportunistic TLS", rather than an		that it is an alternative to "opportunistic TLS", rather than an
	alternative to STARTTLS. While STARTTLS is often used		alternative to STARTTLS. While STARTTLS is often used
	opportunistically, that is not always the case.		opportunistically, that is not always the case.
	o Mention SSL Stripping in Section 3.6 with a reference to		o Mention SSL Stripping in Section 3.6 with a reference to
	Section 2.1 of [RFC7457] because the intent of the related task		Section 2.1 of [RFC7457] because the intent of the related task
	skipping to change at page 14, line 25 ¶		skipping to change at page 14, line 44 ¶
	o Strengthen the requirements on hostname validation and certificate		o Strengthen the requirements on hostname validation and certificate
	verification, by referencing [RFC6125] and [RFC5280].		verification, by referencing [RFC6125] and [RFC5280].
	o Ask IANA to add this document to the NNTP capabilily labels		o Ask IANA to add this document to the NNTP capabilily labels
	registry.		registry.
	o Reference the security considerations of [RFC6125].		o Reference the security considerations of [RFC6125].
	o Mention informative and normative references to add to [RFC4642].		o Mention informative and normative references to add to [RFC4642].
	C.3. Changes since -01		C.4. Changes since -01
	o Take into account all the remarks sent during IETF Last Call.		o Take into account all the remarks sent during IETF Last Call.
	o Move the part about [RFC4642] from Introduction to a new dedicated		o Move the part about [RFC4642] from Introduction to a new dedicated
	Section named "Updates/Changes to RFC 4642" so as to make the		Section named "Updates/Changes to RFC 4642" so as to make the
	document a bit more structured.		document a bit more structured.
	o The warning about lack of STARTTLS is expanded in scope to say		o The warning about lack of STARTTLS is expanded in scope to say
	"during any previous connection within a (possibly configurable)		"during any previous connection within a (possibly configurable)
	time frame" instead of "during the previous connection".		time frame" instead of "during the previous connection".
	skipping to change at page 15, line 16 ¶		skipping to change at page 15, line 35 ¶
	vulnerability.		vulnerability.
	o Add notes to RFC Editor to ask that [MUA-STS] and [NNTP-COMPRESS]		o Add notes to RFC Editor to ask that [MUA-STS] and [NNTP-COMPRESS]
	references be changed to their [RFCxxxx] form, once published, and		references be changed to their [RFCxxxx] form, once published, and
	whether [BCP195] should be used instead of [RFC7525].		whether [BCP195] should be used instead of [RFC7525].
	o Move [RFC5246] (TLS) to a normative reference.		o Move [RFC5246] (TLS) to a normative reference.
	o Minor other wording improvements.		o Minor other wording improvements.
	C.4. Changes since -00		C.5. Changes since -00
	o Clarify in the introduction of Section 3 that NNTP implementations		o Clarify in the introduction of Section 3 that NNTP implementations
	compliant with this document are REQUIRED to also comply with		compliant with this document are REQUIRED to also comply with
	[RFC7525].		[RFC7525].
	o Improve the wording of Section 3.2 to mention that configuration		o Improve the wording of Section 3.2 to mention that configuration
	is primarily intended for news servers. Also, be more consistent		is primarily intended for news servers. Also, be more consistent
	in the options to accept, and include signature algorithms and		in the options to accept, and include signature algorithms and
	named groups.		named groups.
End of changes. 32 change blocks.
	85 lines changed or deleted		105 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/