Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7435 Two Sigma
Category: Informational December 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7435 Two Sigma
Category: Informational December 2014
ISSN: 2070-1721
Opportunistic Security: Some Protection Most of the Time
机会主义安全：大多数情况下的一些保护措施
Abstract
摘要
This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.
本文件定义了通信协议背景下的“机会主义安全”概念。基于机会主义安全的协议设计即使在身份验证不可用时也使用加密，并在可能的情况下使用身份验证，从而消除了在互联网上广泛使用加密的障碍。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7435.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7435.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Background . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. A New Perspective . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Opportunistic Security Design Principles . . . . . . . . . . 5
4. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8
5. Operational Considerations . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. A New Perspective . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Opportunistic Security Design Principles . . . . . . . . . . 5
4. Example: Opportunistic TLS in SMTP . . . . . . . . . . . . . 8
5. Operational Considerations . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
Historically, Internet security protocols have emphasized comprehensive "all or nothing" cryptographic protection against both passive and active attacks. With each peer, such a protocol achieves either full protection or else total failure to communicate (hard fail). As a result, operators often disable these security protocols when users have difficulty connecting, thereby degrading all communications to cleartext transmission.
从历史上看，互联网安全协议强调全面的“全有或全无”密码保护，防止被动和主动攻击。对于每个对等方，这样的协议要么实现完全保护，要么实现完全通信失败（硬故障）。因此，当用户难以连接时，运营商通常会禁用这些安全协议，从而将所有通信降级为明文传输。
Protection against active attacks requires authentication. The ability to authenticate any potential peer on the Internet requires an authentication mechanism that encompasses all such peers. No IETF standard for authentication scales as needed and has been deployed widely enough to meet this requirement.
防止主动攻击需要身份验证。要对Internet上的任何潜在对等方进行身份验证，需要一种包含所有此类对等方的身份验证机制。没有用于认证的IETF标准可以根据需要进行扩展，并且已经广泛部署以满足这一要求。
The Public Key Infrastructure (PKI) model employed by browsers to authenticate web servers (often called the "Web PKI") imposes cost and management burdens that have limited its use. With so many Certification Authorities (CAs), not all of which everyone is willing to trust, the communicating parties don't always agree on a mutually trusted CA. Without a mutually trusted CA, authentication fails, leading to communications failure in protocols that mandate authentication. These issues are compounded by operational difficulties. For example, a common problem is for site operators to forget to perform timely renewal of expiring certificates. In Web PKI interactive applications, security warnings are all too frequent, and end users learn to actively ignore security problems, or site administrators decide that the maintenance cost is not worth the benefit so they provide a cleartext-only service to their users.
浏览器用于验证web服务器的公钥基础设施（PKI）模型（通常称为“web PKI”）带来了成本和管理负担，限制了其使用。由于有这么多的证书颁发机构（CA），并非所有人都愿意信任，通信各方并不总是就相互信任的CA达成一致。如果没有相互信任的CA，身份验证将失败，从而导致授权身份验证的协议中的通信失败。这些问题因业务困难而更加复杂。例如，一个常见问题是站点操作员忘记及时更新过期证书。在Web PKI交互应用程序中，安全警告过于频繁，最终用户学会主动忽略安全问题，或者站点管理员认为维护成本不值得，因此他们向用户提供纯明文服务。
The trust-on-first-use (TOFU) authentication approach assumes that an unauthenticated public key obtained on first contact (and retained for future use) will be good enough to secure future communication. TOFU-based protocols do not protect against an attacker who can hijack the first contact communication and require more care from the end user when systems update their cryptographic keys. TOFU can make it difficult to distinguish routine key management from a malicious attack.
首次使用信任（TOFU）身份验证方法假设在第一次接触时获得的未经验证的公钥（保留供将来使用）足以确保未来通信的安全。基于TOFU的协议无法防止攻击者劫持第一次联系人通信，并且在系统更新其加密密钥时需要最终用户更加小心。TOFU会使常规密钥管理和恶意攻击难以区分。
DNS-Based Authentication of Named Entities (DANE) [RFC6698] defines a way to distribute public keys bound to DNS names. It can provide an alternative to the Web PKI. DANE needs to be used in conjunction with DNSSEC [RFC4033]. At the time of writing, DNSSEC is not sufficiently widely deployed to allow DANE to authenticate all potential peers. Protocols that mandate authenticated communication cannot yet generally do so via DANE (at the time of writing).
基于DNS的命名实体身份验证（DANE）[RFC6698]定义了一种分发绑定到DNS名称的公钥的方法。它可以提供Web PKI的替代方案。丹麦需要与DNSSEC[RFC4033]一起使用。在撰写本文时，DNSSEC的部署还不够广泛，无法让DANE对所有潜在的对等方进行身份验证。授权认证通信的协议通常还不能通过DANE（在编写本文时）实现。
The lack of a global key management system means that for many protocols, only a minority of communications sessions can be predictably authenticated. When protocols only offer a choice between authenticated-and-encrypted communication, or no protection, the result is that most traffic is sent in cleartext. The fact that most traffic is not encrypted makes pervasive monitoring easier by making it cost-effective, or at least not cost-prohibitive (see [RFC7258] for more detail).
缺乏全局密钥管理系统意味着，对于许多协议，只有少数通信会话可以进行可预测的身份验证。当协议只提供认证和加密通信之间的选择，或者不提供保护时，结果是大部分通信以明文发送。大多数流量都没有加密，这一事实使得普遍监控变得更加容易，因为它具有成本效益，或者至少不具有成本禁止性（有关更多详细信息，请参见[RFC7258]）。
For encryption to be used more broadly, authentication needs to be optional. The use of encryption defends against pervasive monitoring and other passive attacks. Even unauthenticated, encrypted communication (defined below) is preferable to cleartext.
为了更广泛地使用加密，身份验证需要是可选的。加密的使用可以抵御无处不在的监视和其他被动攻击。即使是未经验证的加密通信（定义见下文）也比明文更可取。
This document describes a change of perspective. Until now, the protocol designer has viewed protection against both passive and active attacks as the default, and anything short of that as "degraded security" or a "fallback". The new viewpoint is that without specific knowledge of peer capabilities (or explicit configuration or direct request of the application), the default protection is no protection, and anything more than that is an improvement.
本文档描述了视角的变化。到目前为止，协议设计者一直将被动攻击和主动攻击的防护视为默认防护，除此之外的任何防护都视为“安全性降级”或“回退”。新的观点是，如果没有对等功能的特定知识（或应用程序的显式配置或直接请求），默认的保护就没有保护，而超过这一点就是一种改进。
"Opportunistic Security" (OS) is defined as the use of cleartext as the baseline communication security policy, with encryption and authentication negotiated and applied to the communication when available.
“机会主义安全”（Opportunity Security，OS）定义为使用明文作为基线通信安全策略，并在通信可用时协商和应用加密和身份验证。
Cleartext, not comprehensive protection, is the default baseline. An OS protocol is not falling back from comprehensive protection when that protection is not supported by all peers; rather, OS protocols aim to use the maximum protection that is available. (At some point in time for a particular application or protocol all but a negligible fraction of peers might support encryption. At that time, the baseline security might be raised from cleartext to always require encryption, and only authentication would have to be done opportunistically.)
默认基线是明文，而不是全面保护。当一个操作系统协议没有得到所有对等方的支持时，它不会从全面保护中退缩；相反，操作系统协议旨在使用可用的最大保护。（在某个特定应用程序或协议的某个时间点上，除了极少数对等方之外，所有对等方都可能支持加密。那时，基线安全性可能会从明文提高到始终需要加密，并且只需机会主义地进行身份验证。）
To achieve widespread adoption, OS must support incremental deployment. Incremental deployment implies that security capabilities will vary from peer to peer, perhaps for a very long time. OS protocols will attempt to establish encrypted communication whenever both parties are capable of such, and authenticated communication if that is also possible. Thus, use of an OS protocol may yield communication that is authenticated and encrypted, unauthenticated but encrypted, or cleartext. This last outcome will occur if not all parties to a communication support encryption (or if an active attack makes it appear that this is the case).
为了获得广泛采用，操作系统必须支持增量部署。增量部署意味着安全功能将因点而异，可能会持续很长时间。操作系统协议将尝试在双方能够进行加密通信时建立加密通信，并在可能的情况下建立经过身份验证的通信。因此，使用操作系统协议可以产生经过身份验证和加密、未经身份验证但加密或明文的通信。如果不是所有通信方都支持加密（或者如果主动攻击使情况看起来如此），则会出现最后的结果。
When less than complete protection is negotiated, there is no need to prompt the user with "your security may be degraded, please click OK" dialogs. The negotiated protection is as good as can be expected. Even if not comprehensive, it is often better than the traditional outcome of either "no protection" or "communications failure".
当协商的保护不完全时，无需向用户提示“您的安全性可能会降低，请单击“确定”对话框。谈判达成的保护与预期的一样好。即使不全面，也往往比传统的“无保护”或“通信故障”的结果要好。
OS is not intended as a substitute for authenticated, encrypted communication when such communication is already mandated by policy (that is, by configuration or direct request of the application) or is otherwise required to access a particular resource. In essence, OS is employed when one might otherwise settle for cleartext. OS protocols never preempt explicit security policies. A security administrator may specify security policies that override OS. For example, a policy might require authenticated, encrypted communication, in contrast to the default OS security policy.
当策略（即，通过配置或应用程序的直接请求）已经强制要求进行认证、加密通信，或者访问特定资源时，操作系统不打算替代认证、加密通信。本质上，当一个人可能满足于使用明文时，就使用操作系统。操作系统协议从不抢占显式安全策略。安全管理员可以指定覆盖操作系统的安全策略。例如，与默认操作系统安全策略相比，策略可能需要经过身份验证的加密通信。
In this document, the word "opportunistic" carries a positive connotation. Based on advertised peer capabilities, an OS protocol uses as much protection as possible. The adjective "opportunistic" applies to the adaptive choice of security mechanisms peer by peer. Once that choice is made for a given peer, OS looks rather similar to other designs that happen to use the same set of mechanisms.
在本文件中，“机会主义”一词具有积极的含义。基于公布的对等功能，操作系统协议使用尽可能多的保护。形容词“机会主义”适用于对等安全机制的适应性选择。一旦为一个给定的对等机做出了选择，操作系统看起来与使用相同机制集的其他设计非常相似。
The remainder of this document provides definitions of important terms, sets out the OS design principles, and provides an example of an OS design in the context of communication between mail relays.
本文档的其余部分提供了重要术语的定义，阐述了操作系统设计原则，并提供了邮件中继通信环境下的操作系统设计示例。
Trust on First Use (TOFU): In a protocol, TOFU calls for accepting and storing a public key or credential associated with an asserted identity, without authenticating that assertion. Subsequent communication that is authenticated using the cached key or credential is secure against an MiTM attack, if such an attack did not succeed during the vulnerable initial communication. The SSH protocol [RFC4251] in its commonly deployed form makes use of TOFU. The phrase "leap of faith" [RFC4949] is sometimes used as a synonym.
首次使用时信任（TOFU）：在协议中，TOFU调用接受和存储与断言的身份相关联的公钥或凭证，而不验证该断言。如果在易受攻击的初始通信期间，MiTM攻击未成功，则使用缓存的密钥或凭据进行身份验证的后续通信是安全的。SSH协议[RFC4251]以其通常部署的形式使用TOFU。“信仰的飞跃”一词[RFC4949]有时被用作同义词。
Authenticated, encrypted communication: Encrypted communication using a session establishment method in which at least the initiator (or client) authenticates the identity of the acceptor (or server). This is required to protect against both passive and active attacks. Mutual authentication, in which the server also authenticates the client, plays a role in mitigating active attacks when the client and server roles change in the course of a single session.
经过身份验证的加密通信：使用会话建立方法的加密通信，其中至少发起方（或客户端）验证了接收方（或服务器）的身份。这是防止被动和主动攻击所必需的。当客户端和服务器角色在单个会话过程中发生变化时，服务器也对客户端进行身份验证的相互身份验证在减轻主动攻击方面发挥了作用。
Unauthenticated, encrypted communication: Encrypted communication using a session establishment method that does not authenticate the identities of the peers. In typical usage, this means that the initiator (client) has not verified the identity of the target (server), making MiTM attacks possible.
未经验证的加密通信：使用会话建立方法的加密通信，该方法不验证对等方的身份。在典型用法中，这意味着发起方（客户端）未验证目标（服务器）的身份，从而使MiTM攻击成为可能。
Perfect Forward Secrecy (PFS): As defined in [RFC4949].
完美前向保密（PFS）：如[RFC4949]中所定义。
Man-in-the-Middle (MiTM) attack: As defined in [RFC4949].
中间人（MiTM）攻击：定义见[RFC4949]。
OS protocol: A protocol that follows the opportunistic approach to security described herein.
OS协议：遵循本文所述的机会主义安全方法的协议。
OS provides a near-term approach to counter passive attacks by removing barriers to the widespread use of encryption. OS offers an incremental path to authenticated, encrypted communication in the future, as suitable authentication technologies are deployed. OS promotes the following design principles:
操作系统通过消除广泛使用加密的障碍，提供了一种短期方法来对抗被动攻击。随着适当的身份验证技术的部署，操作系统为将来经过身份验证的加密通信提供了一条增量路径。OS提倡以下设计原则：
Coexist with explicit policy: Explicit security policies preempt OS. Opportunistic security never displaces or preempts explicit policy. Many applications and types of data are too sensitive to use OS, and more traditional security designs are appropriate in such cases.
与显式策略共存：显式安全策略抢占操作系统。机会主义安全从未取代或先占明确的政策。许多应用程序和数据类型过于敏感，无法使用操作系统，更传统的安全设计适用于此类情况。
Prioritize communication: The primary goal of OS is to not impede communication while maximizing the deployment of usable security. OS protocols need to be deployable incrementally, with each peer configured independently by its administrator or user. With OS, communication is still possible even when some peers support encryption or authentication and others do not.
优先通信：操作系统的主要目标是不妨碍通信，同时最大限度地部署可用的安全性。操作系统协议需要以增量方式部署，每个对等方由其管理员或用户独立配置。使用操作系统，即使某些对等方支持加密或身份验证，而其他对等方不支持，通信仍然是可能的。
Maximize security peer by peer: OS protocols use encryption when it is mutually supported. OS protocols enforce peer authentication when an authenticated out-of-band channel is available to provide the requisite keys or credentials. In general, communication should be at least encrypted. OS should employ PFS wherever possible in order to protect previously recorded encrypted communication from decryption even after a compromise of long-term keys.
最大化对等安全性：当相互支持时，操作系统协议使用加密。当经过身份验证的带外通道可用于提供必要的密钥或凭据时，操作系统协议强制执行对等身份验证。一般来说，通信至少应该加密。OS应尽可能使用PFS，以保护以前记录的加密通信，即使在长期密钥泄露后也不会被解密。
No misrepresentation of security: Unauthenticated, encrypted communication must not be misrepresented to users or in application logs of non-interactive applications as equivalent to authenticated, encrypted communication.
安全性无误报：未经验证的加密通信不得误报给用户或在非交互应用程序的应用程序日志中，等同于经过验证的加密通信。
An OS protocol first determines the capabilities of the peer with which it is attempting to communicate. Peer capabilities may be discovered by out-of-band or in-band means. (Out-of-band mechanisms include the use of DANE records or cached keys or credentials acquired via TOFU. In-band determination implies negotiation between peers.) The capability determination phase may indicate that the peer supports authenticated, encrypted communication; unauthenticated, encrypted communication; or only cleartext communication.
操作系统协议首先确定它试图与之通信的对等方的能力。对等能力可以通过带外或带内方式发现。（带外机制包括使用DANE记录或通过TOFU获取的缓存密钥或凭证。带内确定意味着对等方之间的协商。）能力确定阶段可能表明对等方支持经过身份验证的加密通信；未经认证的加密通信；或者只有明文通信。
Encryption is used to mitigate the risk of passive monitoring attacks, while authentication is used to mitigate the risk of active MiTM attacks. When encryption capability is advertised over an insecure channel, MiTM downgrade attacks to cleartext may be possible. Since encryption without authentication only mitigates passive attacks, this risk is consistent with the expected level of protection. For authentication to protect against MiTM attacks, the peer capability advertisements that convey support for authentication need to be over an out-of-band authenticated channel that is itself resistant to MiTM attack.
加密用于降低被动监视攻击的风险，而身份验证用于降低主动MiTM攻击的风险。当通过不安全的通道公布加密功能时，MiTM可能会将攻击降级为明文。由于无身份验证的加密只能缓解被动攻击，因此此风险与预期的保护级别一致。为了保护身份验证免受MiTM攻击，传递身份验证支持的对等功能广告需要通过带外身份验证通道，该通道本身能够抵抗MiTM攻击。
Opportunistic security protocols may hard-fail with peers for which a security capability fails to function as advertised. Security services that work reliably (when not under attack) are more likely to be deployed and enabled by default. It is vital that the capabilities advertised for an OS-compatible peer match the deployed reality. Otherwise, OS systems will detect such a broken deployment
机会主义安全协议可能会在对等方中硬失效，而对等方的安全功能无法如广告中所宣传的那样发挥作用。默认情况下，更可能部署和启用工作可靠（不受攻击时）的安全服务。为与操作系统兼容的对等机宣传的功能必须与部署的实际情况相匹配，这一点至关重要。否则，操作系统将检测到这种中断的部署
as an active attack and communication may fail. This might mean that advertised peer capabilities are further filtered to consider only those capabilities that are sufficiently operationally reliable. Capabilities that can't be expected to work reliably should be treated by an OS protocol as "not present" or "undefined".
因为主动攻击和通信可能会失败。这可能意味着广告的对等能力被进一步过滤，以仅考虑那些足够操作可靠性的能力。操作系统协议应将不能可靠工作的功能视为“不存在”或“未定义”。
With unauthenticated, encrypted communication, OS protocols may employ more liberal settings than would be best practice when security is mandated by policy. Some legacy systems support encryption, but implement only outdated algorithms or protocol versions. Compatibility with these systems avoids the need to resort to cleartext fallback.
对于未经验证的加密通信，操作系统协议可能采用比策略强制要求安全性时的最佳做法更自由的设置。一些遗留系统支持加密，但只实现过时的算法或协议版本。与这些系统的兼容性避免了使用明文回退的需要。
For greater assurance of channel security, an OS protocol may enforce more stringent cryptographic parameters when the session is authenticated. For example, the set of enabled Transport Layer Security (TLS) [RFC5246] cipher suites might exclude deprecated algorithms that would be tolerated with unauthenticated, encrypted communication.
为了更好地保证通道安全，当会话经过身份验证时，操作系统协议可以强制执行更严格的加密参数。例如，启用的传输层安全性（TLS）[RFC5246]密码套件集可能会排除未经验证的加密通信所允许的不推荐的算法。
OS protocols should produce authenticated, encrypted communication when authentication of the peer is "expected". Here, "expected" means a determination via a downgrade-resistant method that authentication of that peer is expected to work. Downgrade-resistant methods include: validated DANE DNS records, existing TOFU identity information, and manual configuration. Such use of authentication is "opportunistic", in that it is performed when possible, on a per-session basis.
当对等方的身份验证是“预期的”时，操作系统协议应该产生经过身份验证的加密通信。这里，“预期”是指通过抗降级方法确定该对等方的身份验证预期有效。抗降级方法包括：验证的DANE DNS记录、现有豆腐标识信息和手动配置。这种身份验证的使用是“机会主义”的，因为它是在可能的情况下在每个会话的基础上执行的。
When communicating with a peer that supports encryption but not authentication, any authentication checks enabled by default must be disabled or configured to soft-fail in order to avoid unnecessary communications failure or needless downgrade to cleartext.
当与支持加密但不支持身份验证的对等方通信时，必须禁用默认启用的任何身份验证检查或将其配置为软失败，以避免不必要的通信失败或不必要的降级到明文。
The support of cleartext and the use of outdated algorithms, and especially broken algorithms, is for backwards compatibility with systems already deployed. Protocol designs based on Opportunistic Security prefer to encrypt and prefer to use the best available encryption algorithms available. OS protocols employ cleartext or broken encryption algorithms only with peers that do not appear to be capable of doing otherwise. The eventual desire is to transition away from cleartext and broken algorithms, and particularly for broken algorithms, it is highly desirable to remove such functionality from implementations.
支持明文和使用过时的算法，特别是坏算法，是为了与已经部署的系统向后兼容。基于机会主义安全的协议设计更喜欢加密，并且更喜欢使用可用的最佳加密算法。操作系统协议仅对似乎无法执行其他操作的对等方使用明文或中断加密算法。最终的愿望是从明文和坏的算法过渡，特别是对于坏的算法，从实现中删除这样的功能是非常可取的。
Most Message Transfer Agents (MTAs) [RFC5598] support the STARTTLS [RFC3207] ESMTP extension. MTAs acting as SMTP [RFC5321] clients generally support cleartext transmission of email. They negotiate TLS encryption when the SMTP server announces STARTTLS support. Since the initial ESMTP negotiation is not cryptographically protected, the STARTTLS advertisement is vulnerable to MiTM downgrade attacks.
大多数邮件传输代理（MTA）[RFC5598]支持STARTTLS[RFC3207]ESMTP扩展。MTA作为SMTP[RFC5321]客户端通常支持电子邮件的明文传输。当SMTP服务器宣布STARTTLS支持时，他们协商TLS加密。由于初始ESMTP协商不受加密保护，STARTTLS播发容易受到MiTM降级攻击。
Recent reports from a number of large providers (e.g., [fb-starttls] and [goog-starttls]) suggest that the majority of SMTP email transmission on the Internet is now encrypted, and the trend is toward increasing adoption.
许多大型提供商（如[fb starttls]和[goog starttls]）的最新报告表明，互联网上的大多数SMTP电子邮件传输现在都是加密的，并且越来越多地采用这种方式。
Various MTAs that advertise STARTTLS exhibit interoperability problems in their implementations. As a work-around, it is common for a client MTA to fall back to cleartext when the TLS handshake fails, or when TLS fails during message transmission. This is a reasonable trade-off, since STARTTLS only protects against passive attacks. In the absence of an active attack, TLS failures are generally one of the known interoperability problems.
宣传StartTL的各种MTA在其实现中都存在互操作性问题。作为一种解决方法，当TLS握手失败时，或者当TLS在消息传输过程中失败时，客户端MTA通常会退回到明文。这是一个合理的折衷方案，因为STARTTLS只能防止被动攻击。在没有主动攻击的情况下，TLS故障通常是已知的互操作性问题之一。
Some client MTAs employing STARTTLS abandon the TLS handshake when the server MTA fails authentication and immediately start a cleartext connection. Other MTAs have been observed to accept unverified self-signed certificates, but not expired certificates; again falling back to cleartext. These and similar behaviors are NOT consistent with OS principles, since they needlessly fall back to cleartext when encryption is clearly possible.
当服务器MTA身份验证失败时，一些使用STARTTLS的客户端MTA放弃TLS握手，并立即启动明文连接。观察到其他MTA接受未经验证的自签名证书，但不接受过期证书；再次回到明文。这些和类似的行为不符合操作系统的原则，因为当加密显然是可能的时候，它们不必要地退回到明文。
Protection against active attacks for SMTP is described in [SMTP-DANE]. That document introduces the terms "Opportunistic TLS" and "Opportunistic DANE TLS", and is consistent with the OS design principles defined in this document. With "Opportunistic DANE TLS", authenticated, encrypted communication is enforced with peers for which appropriate DANE records are present. For the remaining peers, "Opportunistic TLS" is employed as before.
[SMTP-DANE]中介绍了针对SMTP主动攻击的保护。该文件介绍了术语“机会主义TLS”和“机会主义丹麦TLS”，并与本文件中定义的操作系统设计原则一致。使用“机会主义DANE TLS”，与存在适当DANE记录的对等方进行认证、加密通信。对于其余的对等方，“机会主义TLS”与以前一样使用。
OS protocol designs should minimize the possibility of failure of negotiated security mechanisms. OS protocols may need to employ "fallback", to work-around a failure of a security mechanisms that is found in practice to encounter interoperability problems. The choice to implement or enable fallback should only be made in response to significant operational obstacles.
操作系统协议设计应尽量减少协商安全机制失败的可能性。操作系统协议可能需要采用“回退”，以解决在实践中发现的遇到互操作性问题的安全机制故障。只有在遇到重大运营障碍时才应选择实施或启用回退。
When protection only against passive attacks is negotiated over a channel vulnerable to active downgrade attacks and the use of encryption fails, a protocol might elect non-intrusive fallback to cleartext. Failure to encrypt may be more often a symptom of an interoperability problem than an active attack. In such a situation, occasional fallback to cleartext may serve the greater good. Even though some traffic is sent in the clear, the alternative is to ask the administrator or user to manually work-around such interoperability problems. If the incidence of such problems is non-negligible, the user or administrator might find it more expedient to just disable Opportunistic Security.
当通过易受主动降级攻击的通道协商仅针对被动攻击的保护，并且加密的使用失败时，协议可能会选择对明文的非侵入性回退。与主动攻击相比，加密失败更可能是互操作性问题的症状。在这种情况下，偶尔回退到明文可能会带来更大的好处。即使某些通信是以明文形式发送的，也可以要求管理员或用户手动解决此类互操作性问题。如果此类问题的发生率不可忽略，则用户或管理员可能会发现禁用机会主义安全性更为方便。
OS supports communication that is authenticated and encrypted, unauthenticated and encrypted, or cleartext. And yet the security provided to communicating peers is not reduced by the use of OS because the default OS policy employs the best security services available based on the capabilities of the peers, and because explicit security policies take precedence over the default OS policy. OS is an improvement over the status quo; it provides better security than the alternative of providing no security services when authentication is not possible (and not strictly required).
操作系统支持经过身份验证和加密、未经身份验证和加密或明文的通信。然而，操作系统的使用并没有降低提供给通信对等方的安全性，因为默认操作系统策略基于对等方的能力采用了可用的最佳安全服务，并且因为显式安全策略优先于默认操作系统策略。操作系统是对现状的改进；它提供了更好的安全性，而不是在不可能进行身份验证（并且不是严格要求）时不提供安全服务。
While the use of OS is preempted by a non-OS explicit policy, such a non-OS policy can be counter-productive when it demands more than many peers can in fact deliver. A non-OS policy should be used with care, lest users find it too restrictive and act to disable security entirely.
虽然操作系统的使用被非操作系统显式策略抢占，但当这种非操作系统策略要求的数量超过许多对等方实际能够提供的数量时，它可能会适得其反。应谨慎使用非操作系统策略，以免用户发现其限制性太强，从而完全禁用安全性。
When protocols follow the OS approach, attackers engaged in large-scale passive monitoring can no longer just collect everything, and have to be more selective and/or mount more active attacks. In addition, OS means active attacks on everyone all the time are much more likely to be noticed.
当协议遵循操作系统的方法时，参与大规模被动监视的攻击者不再只是收集所有信息，必须更具选择性和/或发起更多主动攻击。此外，操作系统意味着随时对每个人的主动攻击更容易被注意到。
Specific techniques for detection and mitigation of active attacks in the absence of authentication are out of scope for this document. Some existing protocols that could support OS may be vulnerable to relatively low-cost downgrade attacks for attackers on the path. However, when such attacks are employed pervasively in order to facilitate, for example, surveillance, this is often detectable; hence, even in such scenarios, OS protocols provide a positive benefit.
在没有身份验证的情况下检测和缓解主动攻击的特定技术不在本文档的范围内。一些可能支持操作系统的现有协议可能容易受到路径上攻击者的相对低成本降级攻击。然而，当这种攻击被广泛使用以促进（例如）监视时，这通常是可检测的；因此，即使在这种情况下，操作系统协议也提供了积极的好处。
Protocols following the OS approach may need to define additional measures to make systematic downgrades less likely to succeed or more likely to be detected. When we have more experience in this space,
遵循操作系统方法的协议可能需要定义额外的措施，使系统降级不太可能成功或更容易被检测到。当我们在这个领域有了更多的经验，
future revisions of this or related documents may be able to make more generally applicable recommendations.
本文件或相关文件的未来修订版可能会提出更普遍适用的建议。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[RFC3207]Hoffman，P.，“传输层安全SMTP的SMTP服务扩展”，RFC 3207，2002年2月<http://www.rfc-editor.org/info/rfc3207>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC4251]Ylonen，T.和C.Lonvick，“安全外壳（SSH）协议架构”，RFC 42512006年1月<http://www.rfc-editor.org/info/rfc4251>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，RFC 49492007年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, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，2012年8月<http://www.rfc-editor.org/info/rfc6698>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.
[RFC5598]Crocker，D.，“互联网邮件体系结构”，RFC 55982009年7月<http://www.rfc-editor.org/info/rfc5598>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[SMTP-DANE] Dukhovni, V. and W. Hardaker, "SMTP security via opportunistic DANE TLS", Work in Progress, draft-ietf-dane-smtp-with-dane-13, October 2014.
[SMTP-DANE]Dukhovni，V.和W.Hardaker，“通过机会主义DANE TLS的SMTP安全”，正在进行的工作，草稿-ietf-DANE-SMTP-with-DANE-13，2014年10月。
[fb-starttls] Facebook, "The Current State of SMTP STARTTLS Deployment", May 2014, <https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/ 1453015901605223>.
[fb starttls]Facebook，“SMTP starttls部署的当前状态”，2014年5月<https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/ 1453015901605223>.
[goog-starttls] Google, "Safer email - Transparency Report - Google", June 2014, <https://www.google.com/transparencyreport/ saferemail/>.
[goog starttls]谷歌，“更安全的电子邮件-透明度报告-谷歌”，2014年6月<https://www.google.com/transparencyreport/ saferemail/>。
Acknowledgements
致谢
I would like to thank Dave Crocker, Peter Duchovni, Paul Hoffman, Benjamin Kaduk, Steve Kent, Scott Kitterman, Pete Resnick, Martin Thomson, Nico Williams, Paul Wouters, and Stephen Farrell for their many helpful suggestions and support.
我要感谢戴夫·克罗克、彼得·杜科夫尼、保罗·霍夫曼、本杰明·卡杜克、史蒂夫·肯特、斯科特·基特曼、皮特·雷斯尼克、马丁·汤姆森、尼科·威廉姆斯、保罗·沃特斯和斯蒂芬·法雷尔，感谢他们提供了许多有益的建议和支持。
Author's Address
作者地址
Viktor Dukhovni Two Sigma
维克多·杜霍夫尼二西格玛
EMail: ietf-dane@dukhovni.org
EMail: ietf-dane@dukhovni.org