[要約] RFC 7435は「Opportunistic Security: Some Protection Most of the Time」と題され、インターネット通信における機会的セキュリティの概念を紹介しています。この文書の目的は、完全なセキュリティソリューションが実現不可能または実装されていない場合でも、可能な限りセキュリティ保護を提供することを奨励することです。利用場面としては、暗号化されていない通信を行うよりも、何らかの保護措置を施した通信を行うことが推奨されます。関連するRFCにはRFC 7436 (Opportunistic Encryption using the Internet Key Exchange (IKEv2))やRFC 7525 (Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS))などがあり、これらは機会的セキュリティの実装やセキュリティプロトコルの使用に関する具体的なガイドラインを提供します。
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.
このドキュメントでは、通信プロトコルのコンテキストで「日和見セキュリティ」の概念を定義しています。 Opportunistic Securityに基づくプロトコル設計は、認証が利用できない場合でも暗号化を使用し、可能な場合は認証を使用することで、インターネットでの暗号化の広範な使用に対する障壁を取り除きます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
アクティブな攻撃に対する保護には認証が必要です。インターネット上の潜在的なピアを認証する機能には、そのようなすべてのピアを含む認証メカニズムが必要です。認証用の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.
trust-on-first-use（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の代替を提供できます。 DANEは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.
「便宜的セキュリティ」（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.)
包括的な保護ではなく、クリアテキストがデフォルトのベースラインです。保護がすべてのピアでサポートされていない場合、OSプロトコルは包括的な保護からフォールバックしません。むしろ、OSプロトコルは、利用可能な最大限の保護を使用することを目的としています。 （特定のアプリケーションまたはプロトコルのある時点で、無視できる割合のピアを除くすべてが暗号化をサポートする可能性があります。その時点で、ベースラインセキュリティはクリアテキストから常に暗号化を要求するように引き上げられ、認証のみが便宜的に行われる必要があります。 ）
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).
広範な採用を実現するには、OSは段階的な導入をサポートする必要があります。増分配備は、おそらく非常に長い間、セキュリティ機能がピアごとに異なることを意味します。 OSプロトコルは、両方の当事者が可能である場合は常に暗号化された通信を確立しようとし、それが可能であれば認証された通信を確立しようとします。したがって、OSプロトコルを使用すると、認証および暗号化された、認証されていないが暗号化された、またはクリアテキストの通信が生成される場合があります。この最後の結果は、通信のすべての関係者が暗号化をサポートしているわけではない場合（またはアクティブな攻撃により、これが事実であるように見える場合）に発生します。
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".
完全ではない保護がネゴシエートされる場合、ユーザーに「セキュリティが低下している可能性があります。OKをクリックしてください」というダイアログを表示する必要はありません。交渉による保護は期待できるほど優れています。包括的ではないとしても、「保護なし」または「通信障害」のいずれかの従来の結果よりも優れていることがよくあります。
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.
OSは、認証済みの暗号化された通信の代用としては意図されていません。そのような通信がすでにポリシーによって（つまり、構成またはアプリケーションの直接要求によって）義務付けられている場合、または特定のリソースにアクセスする必要がある場合です。本質的に、平文で解決するかもしれないときにOSが採用されます。 OSプロトコルは、明示的なセキュリティポリシーを決して横取りしません。セキュリティ管理者は、OSを上書きするセキュリティポリシーを指定できます。たとえば、ポリシーは、デフォルトのOSセキュリティポリシーとは対照的に、認証および暗号化された通信を必要とする場合があります。
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.
このドキュメントでは、「日和見主義的」という言葉は肯定的な意味合いを持っています。アドバタイズされたピア機能に基づいて、OSプロトコルは可能な限り多くの保護を使用します。 「日和見」という形容詞は、ピアツーピアのセキュリティメカニズムの適応選択に適用されます。特定のピアに対してその選択が行われると、OSは、たまたま同じメカニズムのセットを使用する他の設計にかなり似ています。
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.
このドキュメントの残りの部分では、重要な用語の定義を提供し、OS設計の原則を説明し、メールリレー間の通信のコンテキストでのOS設計の例を示します。
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.
Trust on First Use（TOFU）：プロトコルでは、TOFUは、アサーションを認証せずに、アサートされたIDに関連付けられた公開鍵または資格情報を受け入れて保存することを要求します。脆弱な初期通信中に攻撃が成功しなかった場合、キャッシュされたキーまたは資格情報を使用して認証される後続の通信は、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.
認証された暗号化通信：少なくともイニシエーター（またはクライアント）がアクセプター（またはサーバー）のIDを認証するセッション確立方式を使用した暗号化通信。これは、パッシブ攻撃とアクティブ攻撃の両方から保護するために必要です。サーバーもクライアントを認証する相互認証は、単一のセッション中にクライアントとサーバーの役割が変化したときにアクティブな攻撃を軽減する役割を果たします。
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.
認証されていない暗号化通信：ピアのIDを認証しないセッション確立方式を使用した暗号化通信。通常の使用では、これはイニシエーター（クライアント）がターゲット（サーバー）のIDを検証していないため、MiTM攻撃が可能になることを意味します。
Perfect Forward Secrecy (PFS): As defined in [RFC4949].
Perfect Forward Secrecy（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は、暗号化の広範な使用に対する障壁を取り除くことにより、パッシブ攻撃に対抗する短期的なアプローチを提供します。 OSは、適切な認証技術が導入されているため、将来的には認証され暗号化された通信への増分パスを提供します。 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.
明示的なポリシーとの共存：明示的なセキュリティポリシーはOSに優先します。日和見セキュリティは、明示的なポリシーに取って代わったり、横取りしたりすることはありません。多くのアプリケーションとデータのタイプは、OSを使用するには機密性が高すぎるため、そのような場合には、より伝統的なセキュリティ設計が適しています。
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.
通信の優先順位付け：OSの主な目的は、使用可能なセキュリティの展開を最大化しながら通信を妨げないことです。 OSプロトコルは、各ピアがその管理者またはユーザーによって個別に構成された状態で、段階的に展開できる必要があります。 OSでは、暗号化または認証をサポートしているピアとサポートしていないピアがあっても、通信は可能です。
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プロトコルは暗号化を使用します。 OSプロトコルは、必要なキーまたは資格情報を提供するために認証された帯域外チャネルが利用可能な場合、ピア認証を実施します。一般に、通信は少なくとも暗号化する必要があります。 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.
OSプロトコルは、最初に、通信しようとしているピアの機能を決定します。ピア機能は、アウトオブバンドまたはインバンドの方法で検出できます。 （アウトオブバンドメカニズムには、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".
日和見セキュリティプロトコルは、セキュリティ機能がアドバタイズされたとおりに機能しないピアでハードフェイルする場合があります。 （攻撃を受けていない場合に）確実に機能するセキュリティサービスは、デフォルトで展開および有効化される可能性が高くなります。 OS互換のピアにアドバタイズされる機能が、デプロイされた現実と一致することが重要です。そうでない場合、OSシステムは、アクティブな攻撃や通信が失敗する可能性があるため、このような破損したデプロイメントを検出します。これは、アドバタイズされたピア機能がさらにフィルタリングされて、運用上十分に信頼できる機能のみを考慮することを意味する場合があります。確実に機能することが期待できない機能は、OSプロトコルによって「存在しない」または「未定義」として扱われる必要があります。
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.
認証されていない暗号化された通信では、OSプロトコルは、セキュリティがポリシーによって義務付けられている場合のベストプラクティスよりも自由な設定を採用する場合があります。一部のレガシーシステムは暗号化をサポートしていますが、古いアルゴリズムまたはプロトコルバージョンのみを実装しています。これらのシステムとの互換性により、クリアテキストのフォールバックに頼る必要がなくなります。
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.
チャネルセキュリティをより確実に保証するために、セッションが認証されるときに、OSプロトコルはより厳しい暗号化パラメータを適用する場合があります。たとえば、有効化されたトランスポート層セキュリティ（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.
OSプロトコルは、ピアの認証が「期待される」ときに、認証され暗号化された通信を生成する必要があります。ここで、「期待される」とは、そのピアの認証が機能すると予想される、ダウングレード耐性のある方法による決定を意味します。ダウングレード耐性のある方法には、検証済みのDANE DNSレコード、既存のTOFU ID情報、および手動構成があります。このような認証の使用は、セッションごとに可能な場合に実行されるという点で「日和見的」です。
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.
クリアテキストのサポートと古いアルゴリズム、特に壊れたアルゴリズムの使用は、すでに展開されているシステムとの下位互換性のためです。 Opportunistic Securityに基づくプロトコル設計は、暗号化を好み、利用可能な最高の暗号化アルゴリズムを使用することを好みます。 OSプロトコルは、平文または壊れた暗号化アルゴリズムを、他の方法では実行できないように見えるピアでのみ使用します。最終的には、クリアテキストや壊れたアルゴリズムから移行することが望まれます。特に壊れたアルゴリズムでは、実装からそのような機能を削除することが非常に望ましいです。
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拡張をサポートしています。 SMTP [RFC5321]クライアントとして機能するMTAは、通常、電子メールのクリアテキスト送信をサポートしています。 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.
STARTTLSをアドバタイズするさまざまなMTAは、実装に相互運用性の問題を示します。回避策として、TLSハンドシェイクが失敗したとき、またはメッセージの送信中にTLSが失敗したときに、クライアントMTAがクリアテキストにフォールバックするのが一般的です。 STARTTLSはパッシブ攻撃からのみ保護するため、これは妥当なトレードオフです。アクティブな攻撃がない場合、TLS障害は一般に、既知の相互運用性の問題の1つです。
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は検証されていない自己署名証明書を受け入れることが確認されていますが、期限切れの証明書は受け付けていません。再びクリアテキストにフォールバックします。これらと同様の動作は、暗号化が明らかに可能である場合、不必要にクリアテキストにフォールバックするため、OSの原則と一致していません。
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のアクティブな攻撃に対する保護については、[SMTP-DANE]で説明されています。このドキュメントでは、「Opportunistic TLS」および「Opportunistic DANE TLS」という用語を紹介しており、このドキュメントで定義されているOS設計原則と一致しています。 「Opportunistic DANE TLS」では、適切なDANEレコードが存在するピアを使用して、認証および暗号化された通信が実施されます。残りのピアについては、従来どおり「Opportunistic 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.
OSプロトコルの設計では、ネゴシエートされたセキュリティメカニズムの失敗の可能性を最小限に抑える必要があります。 OSプロトコルは、相互運用性の問題に遭遇するために実際に見られるセキュリティメカニズムの失敗を回避するために、「フォールバック」を採用する必要があるかもしれません。フォールバックの実装または有効化の選択は、重大な運用上の障害に応じてのみ行う必要があります。
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).
OSは、認証および暗号化、非認証および暗号化、またはクリアテキストの通信をサポートしています。さらに、デフォルトのOSポリシーはピアの機能に基づいて利用可能な最高のセキュリティサービスを採用し、明示的なセキュリティポリシーはデフォルトのOSポリシーよりも優先されるため、通信するピアに提供されるセキュリティはOSの使用によって低下しません。 OSは現状を改善しています。認証が不可能な場合（厳密には必須ではない）、セキュリティサービスを提供しない代替策よりも優れたセキュリティを提供します。
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.
OSの使用は非OS明示的ポリシーによって優先されますが、そのような非OSポリシーは、多くのピアが実際に提供できるよりも多くを要求する場合、逆効果になります。非OSポリシーは慎重に使用する必要があります。ユーザーがポリシーを制限しすぎて、セキュリティを完全に無効にするように行動しないようにしてください。
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.
プロトコルがOSのアプローチに従うと、大規模なパッシブモニタリングに従事する攻撃者は、すべてを収集するだけでなく、より選択的になるか、よりアクティブな攻撃を行う必要があります。さらに、OSは、誰もが常に攻撃していることに気づく可能性が高いことを意味します。
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.
認証がない場合にアクティブな攻撃を検出して軽減するための特定のテクニックは、このドキュメントの範囲外です。 OSをサポートできるいくつかの既存のプロトコルは、パス上の攻撃者に対する比較的低コストのダウングレード攻撃に対して脆弱である可能性があります。しかしながら、例えば監視を容易にするためにそのような攻撃が広範に利用される場合、これはしばしば検出可能です。したがって、そのようなシナリオであっても、OSプロトコルはプラスの利点を提供します。
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.
OSアプローチに従うプロトコルでは、体系的なダウングレードが成功する可能性が低くなるか、検出される可能性が高くなるように、追加の対策を定義する必要がある場合があります。この分野での経験が豊富な場合、このドキュメントまたは関連ドキュメントの将来の改訂により、より一般的に適用可能な推奨を行うことができる可能性があります。
[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 over Transport Layer Securityの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、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、2006年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 4949、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, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 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。、「Simple Mail Transfer Protocol」、RFC 5321、2008年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。、「Internet Mail Architecture」、RFC 5598、2009年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、「Pervasive Monitoring Is a Attack」、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セキュリティ」、進行中の作業、draft-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] Google、「より安全なメール-透明性レポート-Google」、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.
Dave Crocker、Peter Duchovni、Paul Hoffman、Benjamin Kaduk、Steve Kent、Scott Kitterman、Pete Resnick、Martin Thomson、Nico Williams、Paul Wouters、Stephen Farrellの多くの有益な提案とサポートに感謝します。
Author's Address
著者のアドレス
Viktor Dukhovni Two Sigma
ビクタースピリチュアルツーシグマ
EMail: ietf-dane@dukhovni.org