Internet Engineering Task Force (IETF) J. Elie
Request for Comments: 8143 April 2017
Updates: 4642
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) J. Elie
Request for Comments: 8143 April 2017
Updates: 4642
Category: Standards Track
ISSN: 2070-1721
Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)
将传输层安全（TLS）与网络新闻传输协议（NNTP）结合使用
Abstract
摘要
This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642.
本文档提供了在使用传输层安全性（TLS）时改进网络新闻传输协议（NNTP）安全性的建议。它使TLS的NNTP使用现代化，以符合TLS当前最佳实践。本文档更新了RFC 4642。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8143.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8143.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Updates/Changes to RFC 4642 . . . . . . . . . . . . . . . . . 3
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Protocol Versions and Security Preferences . . . . . . . 4
3.3. Server Name Indication . . . . . . . . . . . . . . . . . 5
3.4. Prevention of SSL Stripping . . . . . . . . . . . . . . . 5
3.5. Authenticated Connections . . . . . . . . . . . . . . . . 5
3.6. Human Factors . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Detailed Changes to RFC 4642 . . . . . . . . . . . . 11
A.1. Related to TLS-Level Compression . . . . . . . . . . . . 11
A.2. Related to Implicit TLS . . . . . . . . . . . . . . . . . 11
A.3. Related to RC4 Cipher Suites . . . . . . . . . . . . . . 12
A.4. Related to Server Name Indication . . . . . . . . . . . . 12
A.5. Related to Certificate Verification . . . . . . . . . . . 12
A.6. Related to Other Obsolete Wording . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Updates/Changes to RFC 4642 . . . . . . . . . . . . . . . . . 3
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Compression . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Protocol Versions and Security Preferences . . . . . . . 4
3.3. Server Name Indication . . . . . . . . . . . . . . . . . 5
3.4. Prevention of SSL Stripping . . . . . . . . . . . . . . . 5
3.5. Authenticated Connections . . . . . . . . . . . . . . . . 5
3.6. Human Factors . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Detailed Changes to RFC 4642 . . . . . . . . . . . . 11
A.1. Related to TLS-Level Compression . . . . . . . . . . . . 11
A.2. Related to Implicit TLS . . . . . . . . . . . . . . . . . 11
A.3. Related to RC4 Cipher Suites . . . . . . . . . . . . . . 12
A.4. Related to Server Name Indication . . . . . . . . . . . . 12
A.5. Related to Certificate Verification . . . . . . . . . . . 12
A.6. Related to Other Obsolete Wording . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
The Network News Transfer Protocol (NNTP) [RFC3977] has been using Transport Layer Security (TLS) [RFC5246] along with its precursor, Secure Sockets Layer (SSL), since at least the year 2000. The use of TLS in NNTP was formalized in [RFC4642], providing implementation recommendations at the same time. In order to address the evolving threat model on the Internet today, this document provides stronger recommendations regarding that use.
至少自2000年以来，网络新闻传输协议（NNTP）[RFC3977]一直在使用传输层安全性（TLS）[RFC5246]及其前身安全套接字层（SSL）。[RFC4642]正式规定了NNTP中TLS的使用，同时提供了实施建议。为了解决当今互联网上不断演变的威胁模型，本文件提供了更有力的建议。
In particular, this document updates [RFC4642] by specifying that NNTP implementations and deployments MUST follow the best current practices documented in [BCP195], which currently consists of RFC 7525 ("Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"). This includes stronger recommendations regarding SSL/TLS protocol versions, fallback to lower versions, TLS negotiation, TLS-level compression, TLS session resumption, cipher suites, public key lengths, forward secrecy, hostname validation, certificate verification, and other aspects of using TLS with NNTP.
特别是，本文件更新了[RFC4642]，规定NNTP实施和部署必须遵循[BCP195]中记录的当前最佳实践，该实践目前包括RFC 7525（“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”）。这包括有关SSL/TLS协议版本、回退到较低版本、TLS协商、TLS级别压缩、TLS会话恢复、密码套件、公钥长度、前向保密性、主机名验证、证书验证以及将TLS与NNTP结合使用的其他方面的更强有力的建议。
Any term not defined in this document has the same meaning as it does in [RFC4642] or the NNTP core specification [RFC3977].
本文件中未定义的任何术语的含义与[RFC4642]或NNTP核心规范[RFC3977]中的含义相同。
When this document uses the term "implicit TLS", it refers to TLS negotiation immediately upon connection on a separate port.
当本文档使用术语“隐式TLS”时，它指的是在单独端口上连接后立即进行TLS协商。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[BCP14]中的说明进行解释。
This document updates [RFC4642] in the following aspects:
本文件在以下方面对[RFC4642]进行了更新：
o NNTP implementations and deployments SHOULD disable TLS-level compression (Section 3.3 of RFC 7525 [BCP195]), thus no longer using TLS as a means to provide data compression (contrary to the Abstract and Section 2.2.2 of [RFC4642]).
o NNTP实施和部署应禁用TLS级压缩（RFC 7525[BCP195]第3.3节），从而不再使用TLS作为提供数据压缩的手段（与[RFC4642]的摘要和第2.2.2节相反）。
o NNTP implementations and deployments SHOULD prefer implicit TLS, and therefore use strict TLS configuration (Section 3.2 of RFC 7525 [BCP195]). That is to say, they SHOULD use a port dedicated to NNTP over TLS and begin the TLS negotiation immediately upon connection (contrary to a dynamic upgrade from unencrypted to TLS-protected traffic via the use of the STARTTLS command, as Section 1 of [RFC4642] was encouraging). Implicit TLS is the preferred way of using TLS with NNTP for the same reasons, transposed to NNTP, as those given in Appendix A of [MUA-STS]. (Note that [MUA-STS] and [RFC4642] have one author in common.)
o NNTP实施和部署应首选隐式TLS，因此应使用严格的TLS配置（RFC 7525[BCP195]第3.2节）。也就是说，他们应该通过TLS使用NNTP专用端口，并在连接后立即开始TLS协商（与通过使用STARTTLS命令从未加密流量动态升级到受TLS保护的流量相反，[RFC4642]的第1节令人鼓舞）。隐式TLS是将TLS与NNTP结合使用的首选方法，原因与[MUA-STS]附录A中给出的原因相同，可转换为NNTP。（请注意，[MUA-STS]和[RFC4642]有一个共同的作者。）
o NNTP implementations and deployments MUST NOT negotiate RC4 cipher suites ([RFC7465]); this is contrary to Section 5 of [RFC4642], which required them to implement the TLS_RSA_WITH_RC4_128_MD5 cipher suite so as to ensure that any two NNTP-compliant implementations can be configured to interoperate. This document removes that requirement, so that NNTP client and server implementations follow the recommendations given in Sections 4.2 and 4.2.1 of RFC 7525 [BCP195] instead. The mandatory-to-implement cipher suite or cipher suites depend on 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 (Section 9 of [RFC5246]).
o NNTP实施和部署不得协商RC4密码套件（[RFC7465]）；这与[RFC4642]的第5节相反，该节要求他们使用_RC4_128_MD5密码套件实现TLS_RSA_，以确保任何两个符合NNTP的实现可以配置为互操作。本文档删除了该要求，因此NNTP客户机和服务器的实现遵循RFC 7525[BCP195]第4.2节和第4.2.1节中给出的建议。实施密码套件或密码套件的强制要求取决于TLS协议版本。例如，当使用TLS 1.2时，必须实现TLS_RSA_和_AES_128_CBC_SHA密码套件（RFC5246第9节）。
o All NNTP clients and any NNTP server that is known by multiple names MUST support the Server Name Indication (SNI) extension defined in Section 3 of [RFC6066], in conformance with Section 3.6 of RFC 7525 [BCP195]. It was only a "SHOULD" in Section 2.2.2 of [RFC4642].
o 根据RFC 7525[BCP195]第3.6节的规定，所有NNTP客户端和任何已知多个名称的NNTP服务器必须支持[RFC6066]第3节中定义的服务器名称指示（SNI）扩展。这只是[RFC4642]第2.2.2节中的“应该”。
o NNTP implementations and deployments MUST follow the rules and guidelines defined in [RFC6125] and [RFC5280] for hostname validation and certificate verification. Part of Section 5 of [RFC4642] is, therefore, rationalized in favor of following those two documents.
o NNTP实施和部署必须遵循[RFC6125]和[RFC5280]中定义的主机名验证和证书验证规则和指南。因此，[RFC4642]第5节的一部分被合理化，以便遵循这两个文件。
Appendix A of this document gives detailed changes with regard to the wording of [RFC4642].
本文件附录A给出了[RFC4642]措辞的详细变更。
The best current practices documented in [BCP195] apply here. Therefore, NNTP implementations and deployments compliant with this document are REQUIRED to comply with [BCP195] as well.
[BCP195]中记录的当前最佳实践适用于此处。因此，符合本文件要求的NNTP实施和部署也必须符合[BCP195]。
Instead of repeating those recommendations here, this document mostly provides supplementary information regarding secure implementation and deployment of NNTP technologies.
本文档主要提供有关NNTP技术安全实施和部署的补充信息，而不是在此重复这些建议。
NNTP supports the use of the COMPRESS command, defined in Section 2.2 of [RFC8054], to compress data between an NNTP client and server. Although this NNTP extension might have slightly stronger security properties than TLS-level compression [RFC3749] (since NNTP compression can be activated after authentication has completed, thus reducing the chances that authentication credentials can be leaked via, for instance, a Compression Ratio Info-leak Made Easy (CRIME) attack, as described in Section 2.6 of [CRIME]), this document neither encourages nor discourages the use of the NNTP COMPRESS extension.
NNTP支持使用[RFC8054]第2.2节中定义的COMPRESS命令来压缩NNTP客户端和服务器之间的数据。尽管此NNTP扩展可能比TLS级压缩[RFC3749]具有更强的安全属性（因为NNTP压缩可以在身份验证完成后激活，从而减少身份验证凭据通过压缩比信息泄漏等方式泄漏的可能性）（犯罪）如[犯罪]第2.6节所述，本文件既不鼓励也不鼓励使用NNTP压缩扩展。
NNTP implementations of news servers are encouraged to support options to configure 1) the minimal TLS protocol version to accept and 2) which cipher suites, signature algorithms, or groups (like elliptic curves) to use for incoming connections. Additional options can naturally also be supported. The goal is to enable administrators of news servers to easily and quickly strengthen security, if needed (for instance, by rejecting cipher suites considered unsafe with regard to local policy).
鼓励新闻服务器的NNTP实现支持以下选项：1）要接受的最小TLS协议版本；2）要用于传入连接的密码套件、签名算法或组（如椭圆曲线）。当然，也可以支持其他选项。其目标是使新闻服务器的管理员能够在需要时轻松快速地加强安全性（例如，拒绝本地策略认为不安全的密码套件）。
News clients may also support similar options, either configurable by the user or enforced by the news reader.
新闻客户端也可以支持类似的选项，可以由用户配置，也可以由新闻阅读器强制执行。
The TLS extension for Server Name Indication (SNI) defined in 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 names. (Otherwise, it is not possible for a server with several hostnames to present the correct certificate to the client.)
[RFC6066]第3节中定义的服务器名称指示（SNI）的TLS扩展必须由所有新闻客户端实现。它还必须由任何已知多个名称的新闻服务器实现。（否则，具有多个主机名的服务器不可能向客户端提供正确的证书。）
In order to help prevent SSL Stripping attacks (Section 2.1 of [RFC7457]), NNTP implementations and deployments MUST follow the recommendations provided in Section 3.2 of RFC 7525 [BCP195]. Notably, in case implicit TLS is not used, news clients SHOULD attempt to negotiate TLS even if the server does not advertise the STARTTLS capability label in response to the CAPABILITIES command (Section 2.1 of [RFC4642]).
为了帮助防止SSL剥离攻击（见[RFC7457]第2.1节），NNTP的实施和部署必须遵循RFC 7525[BCP195]第3.2节中提供的建议。值得注意的是，如果未使用隐式TLS，新闻客户端应尝试协商TLS，即使服务器响应CAPABILITIES命令（RFC4642的第2.1节）未公布STARTTLS功能标签。
[RFC4642] already provides recommendations and requirements for certificate validation in the context of checking the client or the server's identity. Those requirements are strengthened by Appendix A.5 of this document.
[RFC4642]已经在检查客户端或服务器身份的上下文中提供了证书验证的建议和要求。本文件附录A.5加强了这些要求。
Wherever possible, it is best to prefer certificate-based authentication (along with Simple Authentication and Security Layer (SASL) [RFC4422]), and ensure that:
如果可能，最好选择基于证书的身份验证（以及简单身份验证和安全层（SASL）[RFC4422]），并确保：
o Clients authenticate servers.
o 客户端对服务器进行身份验证。
o Servers authenticate clients.
o 服务器对客户端进行身份验证。
o Servers authenticate other peer servers.
o 服务器对其他对等服务器进行身份验证。
This document does not mandate certificate-based authentication, although such authentication is strongly preferred. As mentioned in Section 2.2.2 of [RFC4642], the AUTHINFO SASL command (Section 2.4 of [RFC4643]) with the EXTERNAL mechanism (Appendix A of [RFC4422]) MAY be used to authenticate a client once its TLS credentials have been successfully exchanged.
本文档不强制要求基于证书的身份验证，但强烈建议使用这种身份验证。如[RFC4642]第2.2.2节所述，[RFC4643]第2.4节中的AUTHINFO SASL命令和外部机制（RFC4422]的附录A）可用于在成功交换客户机的TLS凭据后对其进行身份验证。
Given the pervasiveness of eavesdropping [RFC7258], even an encrypted but unauthenticated connection might be better than an unencrypted connection (this is similar to the "better-than-nothing security"
考虑到窃听的普遍性[RFC7258]，即使是加密但未经验证的连接也可能比未加密的连接更好（这类似于“比没有更好的安全性”）
approach for IPsec [RFC5386], and in accordance with opportunistic security principles [RFC7435]). Encrypted but unauthenticated connections include connections negotiated using anonymous Diffie-Hellman mechanisms or using self-signed certificates, among others.
IPsec方法[RFC5386]，并符合机会主义安全原则[RFC7435]）。加密但未经验证的连接包括使用匿名Diffie-Hellman机制或使用自签名证书等协商的连接。
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 the Path header field of that article, to indicate that it verified the identity of the client or peer server. This document encourages the construction of such Path header fields, as described in Section 3.2.1 of [RFC5537].
注意：当NNTP服务器收到Netnews文章时，它可能会添加一个<diag match>（RFC5536的第3.1.5节），该文章的路径头字段中显示为“！！”，以表示它已验证客户端或对等服务器的身份。如[RFC5537]第3.2.1节所述，本文件鼓励构建此类路径头字段。
NNTP clients SHOULD provide ways for end users (and NNTP servers SHOULD provide ways for administrators) to complete at least the following tasks:
NNTP客户端应为最终用户（NNTP服务器应为管理员）提供至少完成以下任务的方法：
o Determine if a given incoming or outgoing connection is encrypted using a security layer (either using TLS or an SASL mechanism that negotiates a security layer).
o 确定给定的传入或传出连接是否使用安全层加密（使用TLS或协商安全层的SASL机制）。
o Be warned if the version of TLS used for encryption of a given stream is not secure enough.
o 如果用于加密给定流的TLS版本不够安全，请发出警告。
o If authenticated encryption is used, determine how the connection was authenticated or verified.
o 如果使用了经过身份验证的加密，请确定连接是如何经过身份验证或验证的。
o Be warned if the certificate offered by an NNTP server cannot be verified.
o 如果无法验证NNTP服务器提供的证书，请发出警告。
o Be warned if the cipher suite used to encrypt a connection is not secure enough.
o 如果用于加密连接的密码套件不够安全，请发出警告。
o Be warned if the certificate changes for a given server.
o 如果给定服务器的证书发生更改，将发出警告。
o When a security layer is not already in place, be warned if a given server stops advertising the STARTTLS capability label in response to the CAPABILITIES command (Section 2.1 of [RFC4642]), whereas it advertised the STARTTLS capability label during any previous connection within a (possibly configurable) time frame. (Otherwise, a human might not see the warning the first time, and the warning would disappear immediately after that.)
o 当安全层尚未就位时，如果给定服务器响应CAPABILITIES命令（RFC4642的第2.1节）停止公布STARTTLS功能标签，而它在（可能可配置的）时间范围内的任何先前连接期间公布STARTTLS功能标签，则应发出警告。（否则，人类可能不会在第一次看到警告，并且警告会立即消失。）
o Be warned if a failure response to the STARTTLS command is received from the server, whereas the STARTTLS capability label was advertised.
o 如果从服务器接收到对STARTTLS命令的失败响应，而STARTTLS功能标签已公布，则会发出警告。
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 Stripping" (Section 2.1 of [RFC7457]).
请注意，使用隐式TLS时，最后两个任务不会发生，倒数第二个任务有助于防止称为“SSL剥离”的攻击（RFC7457的第2.1节）。
Beyond the security considerations already described in [RFC4642], [RFC6125], and [BCP195], the following caveat is worth mentioning when not using implicit TLS: NNTP servers need to ensure that they are not vulnerable to the STARTTLS command injection vulnerability (Section 2.2 of [RFC7457]). Though this command MUST NOT be pipelined, an attacker could pipeline it. Therefore, NNTP servers MUST discard any NNTP command received between the use of STARTTLS and the end of TLS negotiation.
除了[RFC4642]、[RFC6125]和[BCP195]中已经描述的安全注意事项外，在不使用隐式TLS时，以下警告值得一提：NNTP服务器需要确保它们不易受到STARTTLS命令注入漏洞的攻击（参见[RFC7457]第2.2节）。虽然此命令不能通过管道传输，但攻击者可以通过管道传输。因此，NNTP服务器必须丢弃在使用STARTTLS和TLS协商结束之间收到的任何NNTP命令。
This document does not change the formal definition of the STARTTLS extension (Section 6 of [RFC4642]). Nonetheless, as implementations of the STARTTLS extension should follow this document, IANA has added reference to this document to the existing STARTTLS label in the "NNTP Capability Labels" registry contained in the "Network News Transfer Protocol (NNTP) Parameters" registry:
本文件不改变STARTTLS扩展的正式定义（RFC4642第6节）。尽管如此，由于STARTTLS扩展的实现应遵循本文档，IANA已在“网络新闻传输协议（NNTP）参数”注册表中包含的“NNTP能力标签”注册表中的现有STARTTLS标签中添加了对本文档的引用：
+----------+--------------------------+--------------------+
| Label | Meaning | Reference |
+----------+--------------------------+--------------------+
| STARTTLS | Transport layer security | [RFC4642][RFC8143] |
+----------+--------------------------+--------------------+
+----------+--------------------------+--------------------+
| Label | Meaning | Reference |
+----------+--------------------------+--------------------+
| STARTTLS | Transport layer security | [RFC4642][RFC8143] |
+----------+--------------------------+--------------------+
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/bcp14>.
[BCP14]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/bcp14>.
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <https://www.rfc-editor.org/info/bcp195>.
[BCP195]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 75252015年5月<https://www.rfc-editor.org/info/bcp195>.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, DOI 10.17487/RFC3977, October 2006, <http://www.rfc-editor.org/info/rfc3977>.
[RFC3977]Feather，C.，“网络新闻传输协议（NNTP）”，RFC 3977，DOI 10.17487/RFC3977，2006年10月<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>.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<http://www.rfc-editor.org/info/rfc4422>.
[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 2006, <http://www.rfc-editor.org/info/rfc4642>.
[RFC4642]Murchison，K.，Vinocur，J.，和C.Newman，“通过网络新闻传输协议（NNTP）使用传输层安全（TLS）”，RFC 4642，DOI 10.17487/RFC4642，2006年10月<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>.
[RFC4643]Vinocur，J.和K.Murchison，“用于认证的网络新闻传输协议（NNTP）扩展”，RFC 4643，DOI 10.17487/RFC4643，2006年10月<http://www.rfc-editor.org/info/rfc4643>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<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>.
[RFC5536]Murchison，K.，Ed.，Lindsey，C.，和D.Kohn，“网络新闻文章格式”，RFC 5536，DOI 10.17487/RFC5536，2009年11月<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>.
[RFC5537]Allbery，R.，Ed.和C.Lindsey，“网络新闻体系结构和协议”，RFC 5537，DOI 10.17487/RFC5537，2009年11月<http://www.rfc-editor.org/info/rfc5537>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", Ekoparty Security Conference, 2012.
[犯罪]Rizzo，J.和T.Duong，“犯罪袭击”，Ekoparty安全会议，2012年。
[MUA-STS] Moore, K. and C. Newman, "Mail User Agent Strict Transport Security (MUA-STS)", Work in Progress, draft-ietf-uta-email-deep-06, March 2017.
[MUA-STS]Moore，K.和C.Newman，“邮件用户代理严格传输安全（MUA-STS）”，正在进行的工作，草稿-ietf-uta-email-deep-062017年3月。
[PKI-CERT] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, DOI 10.17487/RFC3280, April 2002, <http://www.rfc-editor.org/info/rfc3280>.
[PKI-CERT]Housley，R.，Ford，W.，Polk，T.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 3280，DOI 10.17487/RFC3280，2002年4月<http://www.rfc-editor.org/info/rfc3280>.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, DOI 10.17487/RFC3749, May 2004, <http://www.rfc-editor.org/info/rfc3749>.
[RFC3749]Hollenbeck，S.，“传输层安全协议压缩方法”，RFC 3749，DOI 10.17487/RFC3749，2004年5月<http://www.rfc-editor.org/info/rfc3749>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, DOI 10.17487/RFC5386, November 2008, <http://www.rfc-editor.org/info/rfc5386>.
[RFC5386]Williams，N.和M.Richardson，“比没有更好的安全性：未经验证的IPsec模式”，RFC 5386，DOI 10.17487/RFC5386，2008年11月<http://www.rfc-editor.org/info/rfc5386>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<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>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457]Sheffer，Y.，Holz，R.，和P.Saint Andre，“总结对传输层安全（TLS）和数据报TLS（DTLS）的已知攻击”，RFC 7457，DOI 10.17487/RFC7457，2015年2月<http://www.rfc-editor.org/info/rfc7457>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <http://www.rfc-editor.org/info/rfc7465>.
[RFC7465]Popov，A.，“禁止RC4密码套件”，RFC 7465，DOI 10.17487/RFC7465，2015年2月<http://www.rfc-editor.org/info/rfc7465>.
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, <http://www.rfc-editor.org/info/rfc7590>.
[RFC7590]Saint Andre，P.和T.Alkemade，“在可扩展消息传递和存在协议（XMPP）中使用传输层安全性（TLS）”，RFC 7590，DOI 10.17487/RFC75902015年6月<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>.
[RFC8054]Murchison，K.和J.Elie，“网络新闻传输协议（NNTP）压缩扩展”，RFC 8054，DOI 10.17487/RFC8054，2017年1月<http://www.rfc-editor.org/info/rfc8054>.
This section lists the detailed changes that this document applies to [RFC4642].
本节列出了本文件适用于[RFC4642]的详细变更。
The second sentence in the Abstract in [RFC4642] is replaced with the following text:
[RFC4642]摘要中的第二句替换为以下文本：
The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, and (optional) certificate-based peer entity authentication are also possible.
主要目标是为单链路保密目的提供加密，但数据完整性和（可选）基于证书的对等实体身份验证也是可能的。
The second sentence of the first paragraph in Section 2.2.2 of [RFC4642] is replaced with the following text:
[RFC4642]第2.2.2节第一段第二句替换为以下文本：
The STARTTLS command is usually used to initiate session security, although it can also be used for client and/or server certificate authentication.
STARTTLS命令通常用于启动会话安全性，但也可用于客户端和/或服务器证书身份验证。
The third and fourth paragraphs in Section 1 of [RFC4642] are replaced with the following text:
[RFC4642]第1节第3和第4段替换为以下内容：
TCP port 563 is dedicated to NNTP over TLS, and registered in the IANA Service Name and Transport Protocol Port Number Registry for that usage. NNTP implementations using TCP port 563 begin the TLS negotiation immediately upon connection and then continue with the initial steps of an NNTP session. This immediate TLS negotiation on a separate port (referred to in this document as "implicit TLS") is the preferred way of using TLS with NNTP.
TCP端口563专用于TLS上的NNTP，并在IANA服务名称和传输协议端口号注册表中注册以供使用。使用TCP端口563的NNTP实现在连接后立即开始TLS协商，然后继续NNTP会话的初始步骤。在单独端口上立即协商TLS（在本文档中称为“隐式TLS”）是将TLS与NNTP一起使用的首选方式。
If a host wishes to offer separate servers for transit and reading clients (Section 3.4.1 of [NNTP]), TCP port 563 SHOULD be used for implicit TLS with the reading server, and an unused port of its choice different than TCP port 433 SHOULD be used for implicit TLS with the transit server. The ports used for implicit TLS should be clearly communicated to the clients, and specifically that no plaintext communication occurs before the TLS session is negotiated.
如果主机希望为传输和读取客户端提供单独的服务器（见[NNTP]第3.4.1节），则TCP端口563应用于读取服务器的隐式TLS，并且其选择的不同于TCP端口433的未使用端口应用于传输服务器的隐式TLS。隐式TLS使用的端口应清楚地传达给客户端，特别是在协商TLS会话之前，不会发生明文通信。
As some existing implementations negotiate TLS via a dynamic upgrade from unencrypted to TLS-protected traffic during an NNTP session on well-known TCP ports 119 or 433, this specification
由于一些现有实现在著名的TCP端口119或433上的NNTP会话期间通过从未加密到受TLS保护的流量的动态升级来协商TLS，因此本规范
formalizes the STARTTLS command in use for that purpose. However, as already mentioned above, implementations SHOULD use implicit TLS on a separate port.
形式化用于该目的的STARTTLS命令。但是，如上所述，实现应该在单独的端口上使用隐式TLS。
Note: a common alternative to protect NNTP exchanges with transit servers that do not implement TLS is the use of IPsec with encryption [RFC4301].
注意：保护与未实现TLS的传输服务器之间的NNTP交换的常见替代方案是使用带加密的IPsec[RFC4301]。
An additional informative reference to [RFC4301] is, therefore, added to Section 7.2 of [RFC4642].
因此，在[RFC4642]第7.2节中增加了对[RFC4301]的补充资料性参考。
The third paragraph in Section 5 of [RFC4642] is removed. Consequently, NNTP no longer requires the implementation of any cipher suites, other than those prescribed by TLS (Section 9 of [RFC5246]), and Sections 4.2 and 4.2.1 of RFC 7525 [BCP195].
删除[RFC4642]第5节中的第三段。因此，NNTP不再需要实施任何密码套件，TLS（RFC5246）第9节和RFC 7525[BCP195]第4.2和4.2.1节规定的密码套件除外。
The last two sentences of the seventh paragraph in Section 2.2.2 of [RFC4642] are removed. Section 3.6 of RFC 7525 [BCP195] applies.
删除[RFC4642]第2.2.2节第七段的最后两句话。RFC 7525[BCP195]第3.6节适用。
The text between "During the TLS negotiation" and "identity bindings)." in Section 5 of [RFC4642] is replaced with the following text:
[RFC4642]第5节中“在TLS协商期间”和“身份绑定”之间的文本替换为以下文本：
During TLS negotiation, the client MUST verify the server's identity in order to prevent man-in-the-middle attacks. The client MUST follow the rules and guidelines defined in [RFC6125], where the reference identifier MUST be the server hostname that the client used to open the connection, and that is also specified in the TLS "server_name" extension [RFC6066]. The following NNTP-specific consideration applies: DNS domain names in server certificates MAY contain the wildcard character "*" as the complete leftmost label within the identifier.
在TLS协商期间，客户端必须验证服务器的身份，以防止中间人攻击。客户机必须遵循[RFC6125]中定义的规则和准则，其中引用标识符必须是客户机用于打开连接的服务器主机名，并且在TLS“server_name”扩展[RFC6066]中也有指定。以下NNTP特定注意事项适用：服务器证书中的DNS域名可能包含通配符“*”作为标识符中最左侧的完整标签。
If the match fails, the client MUST follow the recommendations in Section 6.6 of [RFC6125] regarding certificate pinning and fallback.
如果匹配失败，客户机必须遵循[RFC6125]第6.6节中关于证书固定和回退的建议。
Beyond server identity checking, clients also MUST apply the procedures specified in [RFC5280] for general certificate validation (e.g., certificate integrity, signing, and path validation).
除了服务器身份检查外，客户端还必须应用[RFC5280]中指定的程序进行一般证书验证（例如，证书完整性、签名和路径验证）。
Additional normative references to [RFC5280] (replacing [PKI-CERT], which it obsoletes), [RFC6066], and [RFC6125] are, therefore, added to Section 7.1 of [RFC4642].
因此，在[RFC4642]第7.1节中增加了对[RFC5280]（取代[PKI-CERT]的[RFC6066]和[RFC6125]的其他规范性引用。
The first two sentences of the seventh paragraph in Section 2.2.2 of [RFC4642] are removed. There is no special requirement for NNTP with regard to TLS Client Hello messages. Section 7.4.1.2 and Appendix E of [RFC5246] apply.
删除[RFC4642]第2.2.2节第七段的前两句。对于TLS客户端Hello消息，NNTP没有特殊要求。[RFC5246]第7.4.1.2节和附录E适用。
Acknowledgments
致谢
This document draws heavily on ideas in [RFC7590] by Peter Saint-Andre and Thijs Alkemade; a large portion of this text was borrowed from that specification.
本文件大量借鉴了Peter Saint Andre和Thijs Alkemade在[RFC7590]中的观点；本文的大部分内容是从该规范中借来的。
The author would like to thank the following individuals for contributing their ideas and support for writing this specification: Stephane Bortzmeyer, Ben Campbell, Viktor Dukhovni, Stephen Farrell, Sabahattin Gucukoglu, Richard Kettlewell, Jouni Korhonen, Mirja Kuehlewind, David Eric Mandelberg, Matija Nalis, Chris Newman, and Peter Saint-Andre.
作者要感谢以下个人为编写本规范贡献了他们的想法和支持：Stephane Bortzmeyer、Ben Campbell、Viktor Dukhovni、Stephen Farrell、Sabahattin Gucukoglu、Richard Ketterwell、Jouni Korhonen、Mirja Kuehlewind、David Eric Mandelberg、Matija Nalis、Chris Newman和Peter Saint Andre。
Special thanks to Michael Baeuerle, for shepherding this document, and to the Responsible Area Director, Alexey Melnikov, for sponsoring it. They both significantly helped to increase its quality.
特别感谢Michael Baeuerle对本文件的指导，以及区域负责人Alexey Melnikov对本文件的赞助。它们都大大提高了质量。
Author's Address
作者地址
Julien Elie 10 allee Clovis Noisy-le-Grand 93160 France
Julien Elie 10 allee Clovis喧闹勒格兰德93160法国
Email: julien@trigofacile.com
URI: http://www.trigofacile.com/
Email: julien@trigofacile.com
URI: http://www.trigofacile.com/