Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7590 &yet
Updates: 6120 T. Alkemade
Category: Standards Track June 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 7590 &yet
Updates: 6120 T. Alkemade
Category: Standards Track June 2015
ISSN: 2070-1721
Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)
在可扩展消息和状态协议（XMPP）中使用传输层安全性（TLS）
Abstract
摘要
This document provides recommendations for the use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP). This document updates RFC 6120.
本文档提供了在可扩展消息和状态协议（XMPP）中使用传输层安全性（TLS）的建议。本文件更新了RFC 6120。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc7590.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7590.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Support for TLS . . . . . . . . . . . . . . . . . . . . . 3
3.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Session Resumption . . . . . . . . . . . . . . . . . . . 3
3.4. Authenticated Connections . . . . . . . . . . . . . . . . 4
3.5. Server Name Indication . . . . . . . . . . . . . . . . . 5
3.6. Human Factors . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Support for TLS . . . . . . . . . . . . . . . . . . . . . 3
3.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Session Resumption . . . . . . . . . . . . . . . . . . . 3
3.4. Authenticated Connections . . . . . . . . . . . . . . . . 4
3.5. Server Name Indication . . . . . . . . . . . . . . . . . 5
3.6. Human Factors . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] (along with its precursor, the so-called "Jabber protocol") has used Transport Layer Security (TLS) [RFC5246] (along with its precursor, Secure Sockets Layer or SSL) since 1999. Both [RFC6120] and its predecessor [RFC3920] provided recommendations regarding the use of TLS in XMPP. In order to address the evolving threat model on the Internet today, this document provides stronger recommendations.
可扩展消息和状态协议（XMPP）[RFC6120]（及其前身，即所谓的“Jabber协议”）自1999年以来一直使用传输层安全性（TLS）[RFC5246]（及其前身，即安全套接字层或SSL）。[RFC6120]及其前身[RFC3920]都提供了有关在XMPP中使用TLS的建议。为了解决当今互联网上不断演变的威胁模型，本文件提供了更有力的建议。
In particular, this document updates [RFC6120] by specifying that XMPP implementations and deployments MUST follow the best current practices documented in the "Recommendations for Secure Use of TLS and DTLS" [RFC7525]. This includes stronger recommendations regarding SSL/TLS protocol versions, fallback to lower versions, TLS-layer compression, TLS session resumption, cipher suites, public key lengths, forward secrecy, and other aspects of using TLS with XMPP.
特别是，本文档更新了[RFC6120]，规定XMPP实施和部署必须遵循“TLS和DTL安全使用建议”[RFC7525]中记录的当前最佳实践。这包括有关SSL/TLS协议版本、回退到较低版本、TLS层压缩、TLS会话恢复、密码套件、公钥长度、前向保密性以及在XMPP中使用TLS的其他方面的更强有力的建议。
Various security-related terms are to be understood in the sense defined in [RFC4949].
应按照[RFC4949]中定义的含义理解各种安全相关术语。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The best current practices documented in the "Recommendations for Secure Use of TLS and DTLS" [RFC7525] are included here by reference. Instead of repeating those recommendations here, this document mostly provides supplementary information regarding secure implementation and deployment of XMPP technologies.
“TLS和DTL安全使用建议”[RFC7525]中记录的当前最佳实践通过引用包含在此处。本文档主要提供有关XMPP技术的安全实现和部署的补充信息，而不是在此重复这些建议。
Support for TLS (specifically, the XMPP profile of STARTTLS) is mandatory for XMPP implementations, as already specified in [RFC6120] and its predecessor [RFC3920].
正如[RFC6120]及其前身[RFC3920]中所述，XMPP实现必须支持TLS（特别是STARTTLS的XMPP配置文件）。
The server (i.e., the XMPP receiving entity) to which a client or peer server (i.e., the XMPP initiating entity) connects might not offer a stream feature of <starttls xmlns='urn:ietf:params:xml:ns :xmpp-tls'/>. Although in general this stream feature indicates that the server supports and offers TLS, this stream feature might be stripped out by an attacker (see Section 2.1 of [RFC7457]). Similarly, the <required/> child element of the <starttls/> stream feature is used to indicate that negotiation of TLS is mandatory; however, this could also be stripped out by an attacker. Therefore, the initiating entity MUST NOT be deterred from attempting TLS negotiation even if the receiving entity does not advertise support for TLS. Instead, the initiating entity SHOULD (based on local policy) proceed with the stream negotiation and attempt to negotiate TLS.
客户端或对等服务器（即XMPP发起实体）连接的服务器（即XMPP接收实体）可能不提供<starttls xmlns='urn:ietf:params:xml:ns:XMPP tls'/>的流功能。尽管通常此流功能表示服务器支持并提供TLS，但攻击者可能会删除此流功能（请参阅[RFC7457]第2.1节）。类似地，<starttls/>流特征的<required/>子元素用于指示TLS协商是强制性的；但是，攻击者也可能会将其删除。因此，即使接收实体未公布对TLS的支持，也不得阻止发起实体尝试TLS协商。相反，发起实体应该（基于本地策略）继续进行流协商并尝试协商TLS。
XMPP supports an application-layer compression technology [XEP-0138]. Although this XMPP extension might have slightly stronger security properties than TLS-layer compression (since it is enabled after Simple Authentication and Security Layer (SASL) authentication, as described in [XEP-0170]), this document neither encourages nor discourages use of XMPP-layer compression.
XMPP支持应用层压缩技术[XEP-0138]。尽管此XMPP扩展可能比TLS层压缩具有更强的安全属性（因为它是在简单身份验证和安全层（SASL）身份验证之后启用的，如[XEP-0170]中所述），但本文档既不鼓励也不鼓励使用XMPP层压缩。
To improve the reliability of communications over XMPP, it is common practice for clients and servers to implement the stream management extension [XEP-0198]. Although that specification includes a method for resumption of XMPP streams at the application layer, also using session resumption at the TLS layer further optimizes the overall process of resuming an XMPP session (see [XEP-0198] for detailed information). Whether or not XEP-0198 is used for application-layer
为了提高XMPP上通信的可靠性，客户机和服务器通常会实现流管理扩展[XEP-0198]。尽管该规范包括在应用层恢复XMPP流的方法，但在TLS层使用会话恢复也进一步优化了恢复XMPP会话的整个过程（有关详细信息，请参阅[XEP-0198]）。应用层是否使用XEP-0198
session resumption, implementations MUST follow the recommendations provided in [RFC7525] regarding TLS-layer session resumption.
会话恢复，实施必须遵循[RFC7525]中关于TLS层会话恢复的建议。
Both the core XMPP specification [RFC6120] and the CertID specification [RFC6125] provide recommendations and requirements for certificate validation in the context of authenticated connections. This document does not supersede those specifications (e.g., it does not modify the recommendations in [RFC6120] regarding the Subject Alternative Names or other certificate details that need to be supported for authentication of XMPP connections using PKIX certificates).
核心XMPP规范[RFC6120]和CertID规范[RFC6125]都为认证连接上下文中的证书验证提供了建议和要求。本文件不取代这些规范（例如，本文件不修改[RFC6120]中关于使用PKIX证书验证XMPP连接所需的主体替代名称或其他证书详细信息的建议）。
Wherever possible, it is best to prefer authenticated connections (along with SASL [RFC4422]), as already stated in the core XMPP specification [RFC6120]. In particular:
如核心XMPP规范[RFC6120]中所述，在可能的情况下，最好选择经过身份验证的连接（以及SASL[RFC4422]）。特别地：
o Clients MUST authenticate servers.
o 客户端必须对服务器进行身份验证。
o Servers MUST authenticate clients.
o 服务器必须对客户端进行身份验证。
o Servers SHOULD authenticate other servers.
o 服务器应该对其他服务器进行身份验证。
This document does not mandate that servers need to authenticate peer servers, although such authentication is strongly preferred. Unfortunately, in multi-tenanted environments it can be extremely difficult to obtain and deploy PKIX certificates with the proper Subject Alternative Names (see [XMPP-DNA] and [PKIX-POSH] for details). To overcome that difficulty, the Domain Name Associations (DNAs) specification [XMPP-DNA] describes a framework for XMPP server authentication methods, which include not only PKIX but also DNS-Based Authentication of Named Entities (DANE) as defined in [DANE-SRV] and PKIX over Secure HTTP (POSH) as defined in [PKIX-POSH]. These methods can provide a basis for server identity verification when appropriate PKIX certificates cannot be obtained and deployed.
本文档并不要求服务器需要对对等服务器进行身份验证，但强烈建议使用这种身份验证。不幸的是，在多租户环境中，获取和部署具有适当主题替代名称的PKIX证书可能非常困难（有关详细信息，请参阅[XMPP-DNA]和[PKIX-POSH]）。为了克服这一困难，域名关联（DNAs）规范[XMPP-DNA]描述了XMPP服务器身份验证方法的框架，该框架不仅包括[DANE-SRV]中定义的基于DNS的命名实体身份验证（DANE）和[PKIX-POSH]中定义的基于安全HTTP（POSH）的PKIX。当无法获得和部署适当的PKIX证书时，这些方法可以为服务器身份验证提供基础。
Given the pervasiveness of eavesdropping [RFC7258], even an encrypted but unauthenticated connection might be better than an unencrypted connection in these scenarios (this is similar to the "better-than-nothing security" approach for IPsec [RFC5386]). Encrypted but unauthenticated connections include connections negotiated using anonymous Diffie-Hellman mechanisms or using self-signed certificates, among others. In particular for XMPP server-to-server interactions, it can be reasonable for XMPP server implementations to accept encrypted but unauthenticated connections when Server Dialback keys [XEP-0220] are used; such keys on their own provide only weak
鉴于窃听[RFC7258]的普遍性，在这些场景中，即使是加密但未经验证的连接也可能比未加密的连接好（这类似于IPsec[RFC5386]的“比没有更好的安全性”方法）。加密但未经验证的连接包括使用匿名Diffie-Hellman机制或使用自签名证书等协商的连接。特别是对于XMPP服务器到服务器的交互，当使用服务器回拨密钥[XEP-0220]时，XMPP服务器实现接受加密但未经验证的连接是合理的；这些钥匙本身只能提供微弱的信号
identity verification (made stronger through the use of DNSSEC [RFC4033]), but this at least enables encryption of server-to-server connections. The DNA prooftypes mentioned above are intended to mitigate the residual need for encrypted but unauthenticated connections in these scenarios.
身份验证（通过使用DNSSEC[RFC4033]增强），但这至少可以实现服务器到服务器连接的加密。上述DNA验证类型旨在缓解这些场景中对加密但未经验证的连接的剩余需求。
Although there is no harm in supporting the TLS Server Name Indication (SNI) extension [RFC6066], this is not necessary since the same function is served in XMPP by the 'to' address of the initial stream header as explained in Section 4.7.2 of [RFC6120].
尽管支持TLS服务器名称指示（SNI）扩展[RFC6066]并无害处，但这并不是必需的，因为正如[RFC6120]第4.7.2节所述，初始流头的“to”地址在XMPP中提供相同的功能。
It is strongly encouraged that XMPP clients provide ways for end users (and that XMPP servers provide ways for administrators) to complete the following tasks:
强烈建议XMPP客户端为最终用户（以及XMPP服务器为管理员）提供完成以下任务的方法：
o Determine if a given incoming or outgoing XML stream is encrypted using TLS.
o 确定给定的传入或传出XML流是否使用TLS加密。
o Determine the version of TLS used for encryption of a given stream.
o 确定用于加密给定流的TLS版本。
o If authenticated encryption is used, determine how the connection was authenticated or verified (e.g., via PKI, DANE, POSH, or Server Dialback).
o 如果使用经过身份验证的加密，请确定连接是如何经过身份验证或验证的（例如，通过PKI、DANE、POSH或服务器回拨）。
o Inspect the certificate offered by an XMPP server.
o 检查XMPP服务器提供的证书。
o Determine the cipher suite used to encrypt a connection.
o 确定用于加密连接的密码套件。
o Be warned if the certificate changes for a given server.
o 如果给定服务器的证书发生更改，将发出警告。
The use of TLS can help to limit the information available for correlation between the XMPP application layer and the underlying network and transport layers. As typically deployed, XMPP technologies do not leave application-layer routing data (such as XMPP 'to' and 'from' addresses) at rest on intermediate systems, since there is only one hop between any two given XMPP servers. As a result, encrypting all hops (sender's client to sender's server, sender's server to recipient's server, and recipient's server to recipient's client) can help to limit the amount of metadata that might leak.
TLS的使用有助于限制XMPP应用层与底层网络和传输层之间的关联可用信息。正如通常部署的那样，XMPP技术不会将应用层路由数据（如XMPP“到”和“从”地址）留在中间系统上，因为任何两个给定的XMPP服务器之间只有一个跃点。因此，加密所有跃点（发件人的客户端到发件人的服务器、发件人的服务器到收件人的服务器、收件人的服务器到收件人的客户端）有助于限制可能泄漏的元数据量。
It is possible that XMPP servers themselves might be compromised. In that case, per-hop encryption would not protect XMPP communications, and even end-to-end encryption of (parts of) XMPP stanza payloads would leave addressing information and XMPP roster data in the clear. By the same token, it is possible that XMPP clients (or the end-user devices on which such clients are installed) could also be compromised, leaving users utterly at the mercy of an adversary.
XMPP服务器本身可能会受到损害。在这种情况下，每跳加密不会保护XMPP通信，甚至XMPP节有效负载（部分）的端到端加密也会使寻址信息和XMPP花名册数据处于空白状态。出于同样的原因，XMPP客户机（或安装此类客户机的最终用户设备）也可能受到威胁，用户完全受对手摆布。
This document and related actions to strengthen the security of the XMPP network are based on the assumption that XMPP servers and clients have not been subject to widespread compromise. If this assumption is valid, then ubiquitous use of per-hop TLS channel encryption and more significant deployment of end-to-end object encryption technologies will serve to protect XMPP communications to a measurable degree, compared to the alternatives.
本文档和加强XMPP网络安全性的相关行动基于XMPP服务器和客户端未受到广泛危害的假设。如果这一假设是正确的，那么与替代方案相比，每跳TLS信道加密的普遍使用和端到端对象加密技术的更重要部署将有助于在可测量的程度上保护XMPP通信。
This document covers only communication over the XMPP network and does not take into account gateways to non-XMPP networks. As an example, for security considerations related to gateways between XMPP and the Session Initiation Protocol (SIP), see [RFC7247] and [RFC7572].
本文档仅涵盖XMPP网络上的通信，不考虑到非XMPP网络的网关。例如，有关XMPP和会话启动协议（SIP）之间网关的安全注意事项，请参阅[RFC7247]和[RFC7572]。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<http://www.rfc-editor.org/info/rfc4949>.
[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>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.
[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>.
[RFC7525] 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, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[DANE-SRV] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records.", Work in Progress, draft-ietf-dane-srv-14, April 2015.
[DANE-SRV]Finch，T.，Miller，M.，和P.Saint Andre，“使用基于DNS的认证命名实体（DANE）TLSA记录与SRV和MX记录”，正在进行的工作，草稿-ietf-DANE-SRV-14，2015年4月。
[PKIX-POSH] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP (POSH)", Work in Progress, draft-ietf-xmpp-posh-04, February 2015.
[PKIX-POSH]Miller，M.和P.Saint Andre，“基于安全HTTP（POSH）的PKIX”，正在进行的工作，草稿-ietf-xmpp-POSH-042015年2月。
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, DOI 10.17487/RFC3920, October 2004, <http://www.rfc-editor.org/info/rfc3920>.
[RFC3920]Saint Andre，P.，Ed.“可扩展消息和状态协议（XMPP）：核心”，RFC 3920，DOI 10.17487/RFC3920，2004年10月<http://www.rfc-editor.org/info/rfc3920>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[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>.
[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>.
[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>.
[RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling", RFC 7247, DOI 10.17487/RFC7247, May 2014, <http://www.rfc-editor.org/info/rfc7247>.
[RFC7247]Saint Andre，P.，Houri，A.，和J.Hildebrand，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：体系结构、地址和错误处理”，RFC 7247，DOI 10.17487/RFC7247，2014年5月<http://www.rfc-editor.org/info/rfc7247>.
[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>.
[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>.
[RFC7572] Saint-Andre, P., Houri, A., and J. Hildebrand, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging", RFC 7572, DOI 10.17487/RFC7572, June 2015, <http://www.rfc-editor.org/info/rfc7572>.
[RFC7572]Saint Andre，P.，Houri，A.，和J.Hildebrand，“会话启动协议（SIP）和可扩展消息和状态协议（XMPP）之间的互通：即时消息传递”，RFC 7572，DOI 10.17487/RFC7572，2015年6月<http://www.rfc-editor.org/info/rfc7572>.
[XEP-0138] Hildebrand, J. and P. Saint-Andre, "Stream Compression", XSF XEP 0138, May 2009, <http://xmpp.org/extensions/xep-0138.html>.
[XEP-0138]Hildebrand，J.和P.Saint Andre，“流压缩”，XSF XEP 0138，2009年5月<http://xmpp.org/extensions/xep-0138.html>.
[XEP-0170] Saint-Andre, P., "Recommended Order of Stream Feature Negotiation", XSF XEP 0170, January 2007, <http://xmpp.org/extensions/xep-0170.html>.
[XEP-0170]圣安德烈，P.，“流特征协商的建议顺序”，XSF XEP 0170，2007年1月<http://xmpp.org/extensions/xep-0170.html>.
[XEP-0198] Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F., Cridland, D., and M. Wild, "Stream Management", XSF XEP 0198, June 2011, <http://xmpp.org/extensions/xep-0198.html>.
[XEP-0198]Karneges，J.，Saint Andre，P.，Hildebrand，J.，Forno，F.，Cridland，D.，和M.Wild，“河流管理”，XSF XEP 0198，2011年6月<http://xmpp.org/extensions/xep-0198.html>.
[XEP-0220] Miller, J., Saint-Andre, P., and P. Hancke, "Server Dialback", XSF XEP 0220, August 2014, <http://xmpp.org/extensions/xep-0220.html>.
[XEP-0220]Miller，J.，Saint Andre，P.，和P.Hancke，“服务器拨号”，XSF XEP 0220，2014年8月<http://xmpp.org/extensions/xep-0220.html>.
[XMPP-DNA] Saint-Andre, P. and M. Miller, "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, draft-ietf-xmpp-dna-10, March 2015.
[XMPP-DNA]Saint Andre，P.和M.Miller，“可扩展消息和状态协议（XMPP）中的域名关联（DNA）”，正在进行的工作，草稿-ietf-XMPP-DNA-10，2015年3月。
Some governments enforce legislation prohibiting the export of strong cryptographic technologies. Nothing in this document ought to be taken as advice to violate such prohibitions.
一些政府执行立法，禁止出口强加密技术。本文件中的任何内容都不应被视为违反此类禁令的建议。
Acknowledgements
致谢
The authors would like to thank the following individuals for their input: Dave Cridland, Philipp Hancke, Olle Johansson, Steve Kille, Tobias Markmann, Matt Miller, and Rene Treffer.
作者要感谢以下个人的投入：戴夫·克里德兰、菲利普·汉克、奥利·约翰逊、史蒂夫·基尔、托拜厄斯·马克曼、马特·米勒和雷内·特雷弗。
Roni Even caught several important issues in his review on behalf of the General Area Review Team.
Roni甚至代表通用区域审查小组在审查中发现了几个重要问题。
Ben Campbell, Spencer Dawkins, and Barry Leiba provided helpful input during IESG review.
Ben Campbell、Spencer Dawkins和Barry Leiba在IESG审查期间提供了有用的意见。
Thanks to Leif Johansson and Orit Levin as chairs of the UTA WG, Ben Campbell and Joe Hildebrand as chairs of the XMPP WG, and Stephen Farrell as the sponsoring Area Director.
感谢担任UTA工作组主席的Leif Johansson和Orit Levin、担任XMPP工作组主席的Ben Campbell和Joe Hildebrand以及担任赞助区域总监的Stephen Farrell。
Authors' Addresses
作者地址
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
EMail: peter@andyet.com
URI: https://andyet.com/
EMail: peter@andyet.com
URI: https://andyet.com/
Thijs Alkemade
阿尔克马德酒店
EMail: me@thijsalkema.de
EMail: me@thijsalkema.de