[要約] RFC 7696は、暗号アルゴリズムの選択とその柔軟性に関するガイドラインを提供します。この文書の目的は、プロトコル設計者が将来の技術進化や潜在的な脆弱性に対応できるように、暗号アルゴリズムを選択し、実装する際のアジリティ（柔軟性）を確保することです。利用場面は、新しい通信プロトコルの設計や既存のプロトコルの更新時に、セキュリティを確保しつつ将来の変化に対応できるようにすることです。関連するRFCには、暗号化プロトコルやアルゴリズムの選択に関するRFC 8446（TLS 1.3）などがあります。RFC 7696は、暗号化技術の選択における柔軟性と前向きな対応を促すための重要な参考資料です。
Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 7696 Vigil Security
BCP: 201 November 2015
Category: Best Current Practice
ISSN: 2070-1721
Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
暗号化アルゴリズムの俊敏性と実装必須アルゴリズムの選択に関するガイドライン
Abstract
概要
Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.
多くのIETFプロトコルは、暗号化アルゴリズムを使用して、機密性、整合性、認証、またはデジタル署名を提供します。通信するピアは、これらのメカニズムが適切に機能するために、暗号化アルゴリズムの共通セットをサポートする必要があります。このメモは、プロトコルが、ある必須から実装へのアルゴリズムスイートから別のアルゴリズムスイートに時間をかけて移行できるようにするためのガイドラインを提供します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc7696.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7696で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Algorithm Agility Guidelines . . . . . . . . . . . . . . . . . 3
2.1. Algorithm Identifiers . . . . . . . . . . . . . . . . . . 4
2.2. Mandatory-to-Implement Algorithms . . . . . . . . . . . . 5
2.2.1. Platform Specifications . . . . . . . . . . . . . . . 5
2.2.2. Cryptographic Key Size . . . . . . . . . . . . . . . . 5
2.2.3. Providing Notice of Expected Changes . . . . . . . . . 6
2.3. Transitioning from Weak Algorithms . . . . . . . . . . . . 6
2.4. Algorithm Transition Mechanisms . . . . . . . . . . . . . 7
2.5. Cryptographic Key Management . . . . . . . . . . . . . . . 8
2.6. Preserving Interoperability . . . . . . . . . . . . . . . 8
2.7. Balancing Security Strength . . . . . . . . . . . . . . . 9
2.8. Balancing Protocol Complexity . . . . . . . . . . . . . . 10
2.9. Opportunistic Security . . . . . . . . . . . . . . . . . . 10
3. Cryptographic Algorithm Specifications . . . . . . . . . . . . 11
3.1. Choosing Mandatory-to-Implement Algorithms . . . . . . . . 11
3.2. Too Many Choices Can Be Harmful . . . . . . . . . . . . . 12
3.3. Picking One True Cipher Suite Can Be Harmful . . . . . . . 13
3.4. National Cipher Suites . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Normative References . . . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. For interoperability, communicating peers must support a common set of cryptographic algorithms. In most cases, a combination of compatible cryptographic algorithms will be used to provide the desired security services. The set of cryptographic algorithms being used at a particular time is often referred to as a cryptographic algorithm suite or cipher suite. In a protocol, algorithm identifiers might name a single cryptographic algorithm or a full suite of algorithms.
多くのIETFプロトコルは、暗号化アルゴリズムを使用して、機密性、整合性、認証、またはデジタル署名を提供します。相互運用性のために、通信するピアは共通の暗号化アルゴリズムのセットをサポートする必要があります。ほとんどの場合、互換性のある暗号化アルゴリズムの組み合わせを使用して、目的のセキュリティサービスを提供します。特定の時点で使用されている暗号化アルゴリズムのセットは、多くの場合、暗号化アルゴリズムスイートまたは暗号スイートと呼ばれます。プロトコルでは、アルゴリズム識別子は単一の暗号化アルゴリズムまたはアルゴリズムの完全なスイートを示す場合があります。
Cryptographic algorithms age; they become weaker with time. As new cryptanalysis techniques are developed and computing capabilities improve, the work required to break a particular cryptographic algorithm will reduce, making an attack on the algorithm more feasible for more attackers. While it is unknown how cryptoanalytic attacks will evolve, it is certain that they will get better. It is unknown how much better they will become or when the advances will happen. Protocol designers need to assume that advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete. For this reason, protocols need mechanisms to migrate from one algorithm suite to another over time.
暗号化アルゴリズムの古さ。時間とともに弱くなります。新しい暗号解読技術が開発され、コンピューティング機能が向上すると、特定の暗号化アルゴリズムを解読するために必要な作業が減り、アルゴリズムへの攻撃がより多くの攻撃者に実行可能になります。暗号分析攻撃がどのように進化するかは不明ですが、確実に改善されるでしょう。彼らがどれほど良くなるか、いつ進歩が起こるかは不明です。プロトコル設計者は、計算能力の進歩または暗号分析技術の進歩により、最終的にはアルゴリズムが時代遅れになると想定する必要があります。このため、プロトコルには、あるアルゴリズムスイートから別のアルゴリズムスイートに徐々に移行するメカニズムが必要です。
Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time. For the protocol implementer, this means that implementations should be modular to easily accommodate the insertion of new algorithms or suites of algorithms. Ideally, implementations will also provide a way to measure when deployed implementations have shifted away from the old algorithms and to the better ones. For the protocol designer, algorithm agility means that one or more algorithm or suite identifiers must be supported, the set of mandatory-to-implement algorithms will change over time, and an IANA registry of algorithm identifiers will be needed.
アルゴリズムの俊敏性は、プロトコルが1つのアルゴリズムスイートから別のより望ましいアルゴリズムスイートに簡単に移行できる場合に達成されます。プロトコル実装者にとって、これは新しいアルゴリズムまたは一連のアルゴリズムの挿入に容易に対応できるように実装がモジュール化されている必要があることを意味します。理想的には、実装は、デプロイされた実装が古いアルゴリズムからより良いものに移行した時期を測定する方法も提供します。プロトコル設計者にとって、アルゴリズムの俊敏性とは、1つ以上のアルゴリズムまたはスイート識別子をサポートする必要があり、実装から実装までの一連のアルゴリズムが時間とともに変化し、アルゴリズム識別子のIANAレジストリが必要になることを意味します。
Algorithm identifiers by themselves are not sufficient to ensure easy migration. Action by people that maintain implementations and operate services is needed to develop, deploy, and adjust configuration settings to enable the new more desirable algorithms and to deprecate or disable older, less desirable ones. For various reasons, most notably interoperability concerns, experience has shown that it has proven difficult for implementers and administrators to remove or disable weak algorithms. Further, the inability of legacy systems and resource-constrained devices to support new algorithms adds to those concerns. As a result, people live with weaker algorithms, sometimes seriously flawed ones, well after experts recommend migration.
アルゴリズム識別子だけでは、簡単な移行を保証するには不十分です。実装を維持し、サービスを運用する人々によるアクションは、構成設定を開発、展開、および調整して、より望ましい新しいアルゴリズムを有効にし、古くて望ましくないアルゴリズムを非推奨または無効にする必要があります。さまざまな理由、特に相互運用性の懸念により、経験から、実装者と管理者が弱いアルゴリズムを削除または無効にすることは困難であることが証明されています。さらに、レガシーシステムとリソースに制約のあるデバイスが新しいアルゴリズムをサポートできないことは、これらの懸念に追加されます。結果として、専門家が移行を勧めた後も、人々は弱いアルゴリズムで、時には深刻な欠陥のあるアルゴリズムで生活しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
These guidelines are for use by IETF working groups and protocol authors for IETF protocols that make use of cryptographic algorithms. Past attempts at algorithm agility have not been completely successful, and this section provides some insights from those experiences.
これらのガイドラインは、暗号化アルゴリズムを利用するIETFプロトコルのIETFワーキンググループおよびプロトコル作成者が使用するためのものです。アルゴリズムの俊敏性に関する過去の試みは完全には成功していません。このセクションでは、これらの経験からいくつかの洞察を提供します。
IETF protocols that make use of cryptographic algorithms MUST support one or more algorithms or suites. The protocol MUST include a mechanism to identify the algorithm or suite that is being used. An algorithm identifier might be explicitly carried in the protocol. Alternatively, a management mechanism can be used to identify the algorithm. For example, an entry in a key table that includes a key value and an algorithm identifier might be sufficient.
暗号化アルゴリズムを利用するIETFプロトコルは、1つ以上のアルゴリズムまたはスイートをサポートする必要があります。プロトコルには、使用されているアルゴリズムまたはスイートを識別するメカニズムを含める必要があります。アルゴリズム識別子はプロトコルで明示的に運ばれるかもしれません。または、管理メカニズムを使用してアルゴリズムを識別できます。たとえば、キー値とアルゴリズム識別子を含むキーテーブルのエントリで十分な場合があります。
If a protocol does not carry an algorithm identifier, then the protocol version number or some other major change is needed to transition from one algorithm to another. The inclusion of an algorithm identifier is a minimal step toward cryptographic algorithm agility.
プロトコルにアルゴリズム識別子が含まれていない場合、あるアルゴリズムから別のアルゴリズムに移行するには、プロトコルのバージョン番号またはその他の大きな変更が必要です。アルゴリズム識別子を含めることは、暗号化アルゴリズムの俊敏性に向けた最小限のステップです。
Sometimes a combination of protocol version number and explicit algorithm or suite identifiers is appropriate. For example, the Transport Layer Security (TLS) [RFC5246] version number names the default key derivation function, and the cipher suite identifier names the rest of the needed algorithms.
プロトコルバージョン番号と明示的なアルゴリズムまたはスイート識別子の組み合わせが適切な場合があります。たとえば、トランスポート層セキュリティ（TLS）[RFC5246]のバージョン番号はデフォルトの鍵導出関数を示し、暗号スイート識別子は残りの必要なアルゴリズムを示します。
Some approaches carry one identifier for each algorithm that is used. Other approaches carry one identifier for a full suite of algorithms. Both approaches are used in IETF protocols. Designers are encouraged to pick one of these approaches and use it consistently throughout the protocol or family of protocols. Suite identifiers make it easier for the protocol designer to ensure that the algorithm selections are complete and compatible for future assignments. However, suite identifiers inherently face a combinatoric explosion as new algorithms are defined. Algorithm identifiers, on the other hand, impose a burden on implementations by forcing a determination at run-time regarding which algorithm combinations are acceptable.
一部のアプローチでは、使用するアルゴリズムごとに1つの識別子を使用します。他のアプローチでは、アルゴリズムの完全なスイートに対して1つの識別子を使用します。どちらのアプローチもIETFプロトコルで使用されます。設計者は、これらのアプローチの1つを選択し、プロトコルまたはプロトコルファミリ全体で一貫して使用することをお勧めします。スイート識別子を使用すると、プロトコルの設計者は、アルゴリズムの選択が完全であり、将来の割り当てと互換性があることを確認しやすくなります。ただし、スイートアルゴリズムは、新しいアルゴリズムが定義されると、本質的に組み合わせ爆発に直面します。一方、アルゴリズム識別子は、実行時にどのアルゴリズムの組み合わせが許容可能かを判断することを強制することにより、実装に負担をかけます。
Regardless of the approach used, protocols historically negotiate the symmetric cipher and cipher mode together to ensure that they are compatible.
使用されるアプローチに関係なく、プロトコルは、歴史的に対称暗号と暗号モードを一緒にネゴシエートして、互換性を確保します。
In the IPsec protocol suite, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the Authentication Header (AH) [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. Such separation is a completely fine design choice. In contrast, TLS [RFC5246] carries cipher suite identifiers, which is also a completely fine design choice.
IPsecプロトコルスイートでは、インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）[RFC7296]は、認証ヘッダー（AH）[RFC4302]およびカプセル化セキュリティペイロード（ESP）[RFC4303]のアルゴリズム識別子を伝達します。このような分離は、完全に良い設計上の選択です。対照的に、TLS [RFC5246]は暗号スイートの識別子を持ち、これも完全に優れた設計上の選択です。
An IANA registry SHOULD be used for these algorithm or suite identifiers. Once an algorithm identifier is added to the registry, it should not be changed or removed. However, it is desirable to mark a registry entry as deprecated when implementation is no longer advisable.
IANAレジストリは、これらのアルゴリズムまたはスイート識別子に使用する必要があります（SHOULD）。アルゴリズム識別子をレジストリに追加した後は、変更または削除しないでください。ただし、実装が推奨されなくなった場合は、レジストリエントリに非推奨のマークを付けることが望ましいです。
For secure interoperability, BCP 61 [RFC3365] recognizes that communicating peers that use cryptographic mechanisms must support a common set of strong cryptographic algorithms. For this reason, IETF protocols that employ cryptography MUST specify one or more strong mandatory-to-implement algorithms or suites. This does not require all deployments to use this algorithm or suite, but it does require that it be available to all deployments.
安全な相互運用性のために、BCP 61 [RFC3365]は、暗号化メカニズムを使用する通信ピアが強力な暗号化アルゴリズムの共通セットをサポートする必要があることを認識しています。このため、暗号化を採用するIETFプロトコルは、1つ以上の強力な実装必須アルゴリズムまたはスイートを指定する必要があります。これは、すべてのデプロイメントでこのアルゴリズムまたはスイートを使用する必要はありませんが、すべてのデプロイメントで使用できる必要があります。
The IETF needs to be able to change the mandatory-to-implement algorithms over time. It is highly desirable to make this change without updating the base protocol specification. To achieve this goal, it is RECOMMENDED that the base protocol specification includes a reference to a companion algorithms document, allowing the update of one document without necessarily requiring an update to the other. This division also facilitates the advancement of the base protocol specification on the standards maturity ladder even if the algorithm document changes frequently.
IETFは、実装に必須のアルゴリズムを徐々に変更できる必要があります。基本プロトコル仕様を更新せずにこの変更を行うことが強く望まれます。この目標を達成するには、基本プロトコル仕様にコンパニオンアルゴリズムドキュメントへの参照を含めることをお勧めします。これにより、1つのドキュメントの更新を、他のドキュメントの更新を必ずしも必要とせずに行うことができます。この分割により、アルゴリズムドキュメントが頻繁に変更される場合でも、標準成熟度ラダーのベースプロトコル仕様の拡張も容易になります。
The IETF SHOULD keep the set of mandatory-to-implement algorithms small. To do so, the set of algorithms will necessarily change over time, and the transition SHOULD happen before the algorithms in the current set have weakened to the breaking point.
IETFは、実装に必須のアルゴリズムのセットを小さく保つ必要があります（SHOULD）。そうするためには、アルゴリズムのセットは必然的に時間とともに変化し、現在のセットのアルゴリズムが限界点に弱まる前に遷移が発生する必要があります（SHOULD）。
Note that mandatory-to-implement algorithms or suites are not specified for protocols that are embedded in other protocols; in these cases, the system-level protocol specification identifies the mandatory-to-implement algorithm or suite. For example, S/MIME [RFC5751] makes use of the cryptographic message Syntax (CMS) [RFC5652], and S/MIME specifies the mandatory-to-implement algorithms, not CMS. This approach allows other protocols to make use of CMS and make different mandatory-to-implement algorithm choices.
実装に必須のアルゴリズムまたはスイートは、他のプロトコルに埋め込まれているプロトコルには指定されていないことに注意してください。このような場合、システムレベルのプロトコル仕様は、実装が必須のアルゴリズムまたはスイートを識別します。たとえば、S / MIME [RFC5751]は暗号化メッセージ構文（CMS）[RFC5652]を使用し、S / MIMEはCMSではなく、必須から実装へのアルゴリズムを指定します。このアプローチにより、他のプロトコルがCMSを利用し、さまざまな必須から実装までのアルゴリズムを選択できます。
Some cryptographic algorithms are inherently tied to a specific key size, but others allow many different key sizes. Likewise, some algorithms support parameters of different sizes, such as integrity check values or nonces. The algorithm specification MUST identify the specific key sizes and parameter sizes that are to be supported. When more than one key size is available, expect the mandatory-to-implement key size to increase over time.
一部の暗号化アルゴリズムは本質的に特定の鍵サイズに関連付けられていますが、他のアルゴリズムは多くの異なる鍵サイズを許可しています。同様に、一部のアルゴリズムは、整合性チェック値やノンスなど、さまざまなサイズのパラメーターをサポートしています。アルゴリズム仕様は、サポートされる特定のキーサイズとパラメーターサイズを識別しなければなりません。複数のキーサイズを使用できる場合は、実装するために必須のキーサイズが時間とともに増加することを期待してください。
Guidance on cryptographic key size for asymmetric keys can be found in BCP 86 [RFC3766].
非対称鍵の暗号鍵サイズに関するガイダンスは、BCP 86 [RFC3766]にあります。
Guidance on cryptographic key size for symmetric keys can be found in BCP 195 [RFC7525].
対称鍵の暗号鍵サイズに関するガイダンスは、BCP 195 [RFC7525]にあります。
Fortunately, algorithm failures without warning are rare. More often, algorithm transition is the result of age. For example, the transition from DES to Triple-DES to AES took place over decades, causing a shift in symmetric block cipher strength from 56 bits to 112 bits to 128 bits. Where possible, authors SHOULD provide notice to implementers about expected algorithm transitions. One approach that was first used in RFC 4307 [RFC4307] is to use SHOULD+, SHOULD-, and MUST- in the specification of algorithms. The definitions below are slightly modified from those in RFC 4307.
幸いにも、警告なしでアルゴリズムが失敗することはまれです。多くの場合、アルゴリズムの移行は年齢の結果です。たとえば、DESからTriple-DES、AESへの移行は何十年にもわたって行われ、対称ブロック暗号の強度が56ビットから112ビット、128ビットにシフトしました。可能な場合、著者は、予想されるアルゴリズムの遷移について実装者に通知を提供する必要があります（SHOULD）。 RFC 4307 [RFC4307]で最初に使用された1つのアプローチは、アルゴリズムの仕様でSHOULD +、SHOULD-、およびMUST-を使用することです。以下の定義は、RFC 4307の定義からわずかに変更されています。
SHOULD+ This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD+ will be promoted to a MUST in the future.
SHOULD +この用語は、SHOULDと同じことを意味します。ただし、SHOULD +としてマークされたアルゴリズムは、将来的にはMUSTに昇格される可能性があります。
SHOULD- This term means the same as SHOULD. However, it is likely that an algorithm marked as SHOULD- will be deprecated to a MAY or worse in the future.
SHOULD-この用語は、SHOULDと同じことを意味します。ただし、SHOULD-とマークされたアルゴリズムは、将来的には非推奨（MAY）になる可能性があります。
MUST- This term means the same as MUST. However, it is expected that an algorithm marked as MUST- will be downgraded in the future. Although the status of the algorithm will be determined at a later time, it is reasonable to expect that a the status of a MUST-algorithm will remain at least a SHOULD or a SHOULD-.
MUST-この用語は、MUSTと同じことを意味します。ただし、MUST-とマークされたアルゴリズムは、将来ダウングレードされることが予想されます。アルゴリズムのステータスは後で決定されますが、MUST-アルゴリズムのステータスが少なくともSHOULDまたはSHOULD-のままであることを期待することは合理的です。
Transition from an old algorithm that is found to be weak can be tricky. It is of course straightforward to specify the use of a new, better algorithm. And then, when the new algorithm is widely deployed, the old algorithm ought no longer be used. However, knowledge about the implementation and deployment of the new algorithm will always be imperfect, so one cannot be completely assured of interoperability with the new algorithm.
弱いことが判明している古いアルゴリズムからの移行は注意が必要です。もちろん、新しいより優れたアルゴリズムの使用を指定するのは簡単です。そして、新しいアルゴリズムが広く導入されると、古いアルゴリズムは使用されなくなります。ただし、新しいアルゴリズムの実装と展開に関する知識は常に不完全であるため、新しいアルゴリズムとの相互運用性を完全に保証することはできません。
Algorithm transition is naturally facilitated as part of an algorithm selection or negotiation mechanism. Protocols traditionally select the best algorithm or suite that is supported by all communicating peers and acceptable by their policies. In addition, a mechanism is needed to determine whether the new algorithm has been deployed. For example, SMIMECapabilities [RFC5751] allows S/MIME mail user agents to share the list of algorithms that they are willing to use in preference order. For another example, the DNSSEC EDNS0 option [RFC6975] measures the acceptance and use of new digital signing algorithms.
アルゴリズムの移行は、アルゴリズムの選択またはネゴシエーションメカニズムの一部として自然に促進されます。プロトコルは伝統的に、すべての通信するピアによってサポートされ、それらのポリシーによって受け入れられる最良のアルゴリズムまたはスイートを選択します。さらに、新しいアルゴリズムが展開されているかどうかを判別するメカニズムが必要です。たとえば、SMIMECapabilities [RFC5751]を使用すると、S / MIMEメールユーザーエージェントは、優先順位で使用するアルゴリズムのリストを共有できます。別の例として、DNSSEC EDNS0オプション[RFC6975]は、新しいデジタル署名アルゴリズムの受け入れと使用を測定します。
In the Resource Public Key Infrastructure (RPKI), a globally recognized digital signature is needed. BCP 182 [RFC6916] provides an approach to transition, where a second signature algorithm is introduced and then the original one is phased out.
Resource Public Key Infrastructure（RPKI）では、世界的に認められたデジタル署名が必要です。 BCP 182 [RFC6916]は、第2の署名アルゴリズムが導入された後、元のアルゴリズムが段階的に廃止される移行アプローチを提供します。
In the worst case, the old algorithm may be found to be tragically flawed, permitting a casual attacker to download a simple script to break it. Sadly, this has happened when a secure algorithm is used incorrectly or used with poor key management, resulting in a weak cryptographic algorithm suite. In such situations, the protection offered by the algorithm is severely compromised, perhaps to the point that one wants to stop using the weak suite altogether, rejecting offers to use the weak suite well before the new suite is widely deployed.
最悪の場合、古いアルゴリズムに悲劇的な欠陥が見つかる可能性があり、カジュアルな攻撃者が簡単なスクリプトをダウンロードしてそれを破ることができます。悲しいことに、これは、安全なアルゴリズムが誤って使用されたり、不十分な鍵管理で使用されたりした場合に発生し、その結果、暗号アルゴリズムスイートが脆弱になります。このような状況では、アルゴリズムによって提供される保護が大幅に侵害され、おそらく弱いスイートの使用を完全に停止し、新しいスイートが広く導入されるかなり前に弱いスイートの使用の提案を拒否します。
In any case, there comes a point in time where one refuses to use the old, weak algorithm or suite. This can happen on a flag day, or each installation can select a date on their own.
いずれにせよ、古くて弱いアルゴリズムやスイートを使用することを拒否する時が来ます。これは、旗の日に発生する可能性があります。または、インストールごとに独自に日付を選択できます。
Cryptographic algorithm selection or negotiation SHOULD be integrity protected. If selection is not integrity protected, then the protocol will be subject to a downgrade attack. Without integrity protection of algorithm or suite selection, the attempt to transition to a new algorithm or suite may introduce new opportunities for downgrade attacks.
暗号化アルゴリズムの選択またはネゴシエーションは、完全性を保護する必要があります。選択が整合性保護されていない場合、プロトコルはダウングレード攻撃を受ける可能性があります。アルゴリズムまたはスイート選択の整合性保護がない場合、新しいアルゴリズムまたはスイートに移行しようとすると、ダウングレード攻撃の新たな機会がもたらされる可能性があります。
Transition mechanisms need to consider the algorithm that is used to provide integrity protection for algorithm negotiation itself.
遷移メカニズムでは、アルゴリズムネゴシエーション自体の整合性保護を提供するために使用されるアルゴリズムを考慮する必要があります。
If a protocol specifies a single mandatory-to-implement integrity algorithm, eventually that algorithm will be found to be weak.
プロトコルで単一の必須から実装までの整合性アルゴリズムが指定されている場合、最終的にそのアルゴリズムは脆弱であることがわかります。
Extra care is needed when a mandatory-to-implement algorithm is used to provide integrity protection for the negotiation of other cryptographic algorithms. In this situation, a flaw in the mandatory-to-implement algorithm may allow an attacker to influence the choices of the other algorithms.
他の暗号化アルゴリズムのネゴシエーションに整合性保護を提供するために必須の実装アルゴリズムを使用する場合は、さらに注意が必要です。この状況では、実装必須アルゴリズムの欠陥により、攻撃者が他のアルゴリズムの選択に影響を与える可能性があります。
Traditionally, protocol designers have avoided more than one approach to exchanges that establish cryptographic keys because it makes the security analysis of the overall protocol more difficult. When frameworks such as the Extensible Authentication Protocol (EAP) [RFC3748] and Simple Authentication and Security Layer (SASL) [RFC4422] are employed, key establishment is very flexible, often hiding many of the details from the application. This results in protocols that support multiple key establishment approaches. In fact, the key establishment approach itself is negotiable, which creates a design challenge to protect the negotiation of the key establishment approach before it is used to produce cryptographic keys.
従来、プロトコル設計者は、プロトコル全体のセキュリティ分析をより困難にするため、暗号化キーを確立する交換への複数のアプローチを避けてきました。 Extensible Authentication Protocol（EAP）[RFC3748]やSimple Authentication and Security Layer（SASL）[RFC4422]などのフレームワークが採用されている場合、キーの確立は非常に柔軟であり、多くの場合、アプリケーションから多くの詳細が隠されます。これにより、複数のキー確立アプローチをサポートするプロトコルが得られます。実際、キー確立アプローチ自体は交渉可能であり、暗号化キーの生成に使用される前に、キー確立アプローチの交渉を保護するという設計上の課題が生じます。
Protocols can negotiate a key establishment approach, derive an initial cryptographic key, and then authenticate the negotiation. However, if the authentication fails, the only recourse is to start the negotiation over from the beginning.
プロトコルは、キー確立アプローチをネゴシエートし、最初の暗号化キーを導出して、ネゴシエーションを認証できます。ただし、認証が失敗した場合の唯一の手段は、交渉を最初からやり直すことです。
Some environments will restrict the key establishment approaches by policy. Such policies tend to improve interoperability within a particular environment, but they cause problems for individuals that need to work in multiple incompatible environments.
一部の環境では、ポリシーによって主要な確立アプローチが制限されます。このようなポリシーは、特定の環境内での相互運用性を向上させる傾向がありますが、互換性のない複数の環境で作業する必要がある個人に問題を引き起こします。
Cryptographic algorithm deprecation is very difficult. People do not like to introduce interoperability problems, even to preserve security. As a result, flawed algorithms are supported for far too long. The impact of legacy software and long support tails on security can be reduced by making it easy to transition from old algorithms and suites to new ones. Social pressure is often needed to cause the transition to happen.
暗号アルゴリズムの廃止は非常に困難です。人々は、セキュリティを維持するためでさえ、相互運用性の問題を導入することを好まない。その結果、欠陥のあるアルゴリズムが非常に長い間サポートされます。レガシーソフトウェアと長いサポートテールがセキュリティに与える影響は、古いアルゴリズムとスイートから新しいアルゴリズムとスイートに簡単に移行できるようにすることで軽減できます。移行を起こすために社会的圧力がしばしば必要です。
Implementers have been reluctant to remove deprecated algorithms or suites from server software, and server administrators have been reluctant to disable them over concerns that some party will no longer have the ability to connect to their server. Implementers and administrators want to improve security by using the best supported algorithms, but their actions are tempered by the desire to preserve connectivity. Recently, some browser vendors have started to provide visual warnings when a deprecated algorithm or suite is used. These visual warnings provide a new incentive to transition away from deprecated algorithms and suites, prompting customers to ask for improved security.
実装者は非推奨のアルゴリズムやスイートをサーバーソフトウェアから削除することに消極的であり、サーバー管理者は一部の当事者がサーバーに接続できなくなるという懸念からそれらを無効にすることに消極的でした。実装者と管理者は、サポートされている最良のアルゴリズムを使用してセキュリティを向上させたいと考えていますが、接続を維持したいという欲求によってアクションが抑制されています。最近、一部のブラウザーベンダーは、非推奨のアルゴリズムまたはスイートが使用されたときに視覚的な警告を提供し始めました。これらの視覚的な警告は、非推奨のアルゴリズムやスイートから移行するための新しいインセンティブを提供し、セキュリティの向上を顧客に求めるよう促します。
Transition in Internet infrastructure is particularly difficult. The digital signature on the certificate for an intermediate certification authority (CA) [RFC5280] is often expected to last decades, which hinders the transition away from a weak signature algorithm or short key length. Once a long-lived certificate is issued with a particular signature algorithm, that algorithm will be used by many relying parties, and none of them can stop supporting it without invalidating all of the subordinate certificates. In a hierarchical system, many subordinate certificates could be impacted by the decision to drop support for a weak signature algorithm or an associated hash function.
インターネットインフラストラクチャの移行は特に困難です。中間証明機関（CA）の証明書のデジタル署名[RFC5280]は、数十年続くことがよくあり、弱い署名アルゴリズムや短いキー長からの移行を妨げます。長期間有効な証明書が特定の署名アルゴリズムで発行されると、そのアルゴリズムは多くの証明書利用者によって使用され、下位の証明書をすべて無効にすることなく、そのサポートを停止することはできません。階層システムでは、多くの下位証明書が、弱い署名アルゴリズムまたは関連するハッシュ関数のサポートを中止する決定の影響を受ける可能性があります。
Organizations that have a significant influence can assist by coordinating the demise of an algorithm suite, making the transition easier for their own users as well as others.
大きな影響力を持つ組織は、アルゴリズムスイートの廃止を調整することによって支援でき、自分のユーザーだけでなく他のユーザーも簡単に移行できるようにします。
When selecting or negotiating a suite of cryptographic algorithms, the strength of each algorithm SHOULD be considered. The algorithms in a suite SHOULD be roughly equal by providing comparable best-known attack work factors. However, the security service provided by each algorithm in a particular context needs to be considered when making the selection. Algorithm strength needs to be considered at the time a protocol is designed. It also needs to be considered at the time a protocol implementation is deployed and configured. Advice from experts is useful, but, in reality, such advice is often unavailable to system administrators that are deploying a protocol implementation. For this reason, protocol designers SHOULD provide clear guidance to implementers, leading to balanced options being available at the time of deployment.
一連の暗号化アルゴリズムを選択または交渉するときは、各アルゴリズムの強度を考慮する必要があります（SHOULD）。スイート内のアルゴリズムは、同等の最もよく知られている攻撃の作業要素を提供することにより、おおよそ等しい必要があります。ただし、選択を行うときは、特定のコンテキストで各アルゴリズムによって提供されるセキュリティサービスを考慮する必要があります。プロトコルの設計時にアルゴリズムの強度を考慮する必要があります。また、プロトコルの実装を展開および構成するときにも考慮する必要があります。専門家からのアドバイスは有用ですが、実際には、プロトコルの実装を展開しているシステム管理者は、そのようなアドバイスを利用できないことがよくあります。このため、プロトコル設計者は実装者に明確なガイダンスを提供する必要があり（SHOULD）、展開時に利用可能なバランスのとれたオプションにつながります。
Performance is always a factor is selecting cryptographic algorithms. Performance and security need to be balanced. Some algorithms offer flexibility in their strength by adjusting the key size, number of rounds, authentication tag size, prime group size, and so on. For example, TLS cipher suites include Diffie-Hellman or RSA without specifying a particular public key length. If the algorithm identifier or suite identifier named a particular public key length, migration to longer ones would be more difficult. On the other hand, inclusion of a public key length would make it easier to migrate away from short ones when computational resources available to attacker dictate the need to do so. The flexibility on asymmetric key length has led to interoperability problems, and to avoid these problems in the future any aspect of the algorithm not specified by the algorithm identifiers need to be negotiated, including key size and parameters.
パフォーマンスは常に暗号化アルゴリズムを選択する際の要素です。パフォーマンスとセキュリティのバランスをとる必要があります。一部のアルゴリズムは、鍵のサイズ、ラウンド数、認証タグのサイズ、プライムグループのサイズなどを調整することで、強度に柔軟性をもたらします。たとえば、TLS暗号スイートには、特定の公開鍵の長さを指定しないDiffie-HellmanまたはRSAが含まれています。アルゴリズム識別子またはスイート識別子が特定の公開鍵の長さを指定している場合、より長いものへの移行はより困難になります。一方、公開鍵の長さを含めることで、攻撃者が利用できる計算リソースがそうする必要性を示した場合、短いものから移行することが容易になります。非対称キー長の柔軟性により相互運用性の問題が発生しました。今後これらの問題を回避するには、キーサイズやパラメーターなど、アルゴリズム識別子で指定されていないアルゴリズムのあらゆる側面について交渉する必要があります。
In CMS [RFC5652], a previously distributed symmetric key-encryption key can be used to encrypt a content-encryption key, which in turn is used to encrypt the content. The key-encryption and content-encryption algorithms are often different. If, for example, a message content is encrypted with a 128-bit AES key and the content-encryption key is wrapped with a 256-bit AES key, then at most 128 bits of protection is provided. In this situation, the algorithm and key size selections should ensure that the key encryption is at least as strong as the content encryption. In general, wrapping one key with another key of a different size yields the security strength of the shorter key.
CMS [RFC5652]では、以前に配布された対称キー暗号化キーを使用して、コンテンツ暗号化キーを暗号化できます。コンテンツ暗号化キーは、コンテンツの暗号化に使用されます。キー暗号化アルゴリズムとコンテンツ暗号化アルゴリズムは、多くの場合異なります。たとえば、メッセージコンテンツが128ビットAESキーで暗号化され、コンテンツ暗号化キーが256ビットAESキーでラップされている場合、最大128ビットの保護が提供されます。この状況では、アルゴリズムとキーサイズを選択することで、キーの暗号化が少なくともコンテンツの暗号化と同じくらい強力になるようにする必要があります。一般に、あるキーを別のサイズの別のキーでラップすると、短い方のキーのセキュリティ強度が高まります。
Protocol designs need to anticipate changes in the supported cryptographic algorithm set over time. There are a number of ways to enable the transition, and Section 3 discusses some of the related issues.
プロトコルの設計では、サポートされる暗号化アルゴリズムセットの経時的な変化を予測する必要があります。移行を可能にする方法はいくつかあり、セクション3では関連する問題のいくつかについて説明します。
Keep implementations as simple as possible. Complex protocol negotiation provides opportunities for attack, such as downgrade attacks. Support for many algorithm alternatives is also harmful. Both of these can lead to portions of the implementation that are rarely used, increasing the opportunity for undiscovered exploitable implementation bugs.
実装はできるだけシンプルにしてください。複雑なプロトコルネゴシエーションは、ダウングレード攻撃などの攻撃の機会を提供します。多くの代替アルゴリズムのサポートも有害です。これらは両方とも、めったに使用されない実装の部分につながり、発見されていない悪用可能な実装バグの機会を増やす可能性があります。
Despite the guidance in Section 2.4, opportunistic security [RFC7435] also deserves consideration, especially at the time a protocol implementation is deployed and configured. Opportunistic security, like other reasons for encrypting traffic, needs to make use of the strongest encryption algorithms that are implemented and allowed by policy. When communicating parties do not have strong algorithms in common, using algorithms that are weak against advanced attackers but sufficient against others is one way to make pervasive surveillance significantly more difficult. As a result, when communicating parties do not have strong algorithms in common, algorithms that would not be acceptable in many negotiated situations are acceptable for opportunistic security when legacy systems are in use for unauthenticated encrypted sessions (as discussed in Section 3 of [RFC7435]) as long as their use does not facilitate downgrade attacks. Similarly, weaker algorithms and shorter key sizes are also acceptable for opportunistic security with the same constraints.
セクション2.4のガイダンスにもかかわらず、日和見セキュリティ[RFC7435]も考慮に値します。特に、プロトコル実装が展開および構成されている場合はそうです。日和見セキュリティは、トラフィックを暗号化する他の理由と同様に、ポリシーによって実装および許可されている最も強力な暗号化アルゴリズムを利用する必要があります。通信相手に共通の強力なアルゴリズムがない場合、高度な攻撃者には弱いが他のユーザーには十分であるアルゴリズムを使用することは、広域監視を著しく困難にする1つの方法です。その結果、通信相手に共通の強力なアルゴリズムがない場合、レガシーシステムが非認証の暗号化セッションで使用されている場合、多くの交渉状況では受け入れられないアルゴリズムが日和見セキュリティに受け入れられます（[RFC7435]のセクション3で説明）。 ）それらの使用がダウングレード攻撃を促進しない限り。同様に、弱いアルゴリズムと短いキーサイズも、同じ制約のある日和見セキュリティには受け入れられます。
That said, the use of strong algorithms is always preferable.
とはいえ、強力なアルゴリズムを使用することが常に望ましいです。
There are tradeoffs between the number of cryptographic algorithms that are supported and the time to deploy a new algorithm. This section provides some of the insights about the tradeoff faced by protocol designers.
サポートされる暗号化アルゴリズムの数と新しいアルゴリズムを展開する時間の間にはトレードオフがあります。このセクションでは、プロトコル設計者が直面するトレードオフに関するいくつかの洞察を提供します。
Ideally, two independent sets of mandatory-to-implement algorithms will be specified, allowing for a primary suite and a secondary suite. This approach ensures that the secondary suite is widely deployed if a flaw is found in the primary one.
理想的には、必須から実装までのアルゴリズムの2つの独立したセットが指定され、プライマリスイートとセカンダリスイートが可能になります。このアプローチにより、プライマリスイートに欠陥が見つかった場合にセカンダリスイートが広く展開されます。
It may seem as if the ability to use an algorithm of one's own choosing is very desirable; however, the selection is often better left to experts. When there are choices, end-users might select between configuration profiles that have been defined by experts. Further, experts need not specify each and every cryptographic algorithm alternative. Specifying all possible choices will not lead to them all being available in every implementation. Mandatory-to-implement algorithms MUST have a stable public specification and public documentation that has been well studied, giving rise to significant confidence. The IETF has always had a preference for unencumbered algorithms. There are significant benefits in selecting algorithms and suites that are widely deployed. The selected algorithms need to be resistant to side-channel attacks and also meet the performance, power, and code size requirements on a wide variety of platforms. In addition, inclusion of too many alternatives may add complexity to algorithm selection or negotiation. Specification of too many alternatives will likely hamper interoperability and may hamper security as well. When specifying new algorithms or suites, protocol designers would be prudent to consider whether existing ones can be deprecated.
自分で選択したアルゴリズムを使用できることが非常に望ましいように思えるかもしれません。ただし、選択は多くの場合、専門家に任せるのが適切です。選択肢がある場合、エンドユーザーは専門家によって定義された構成プロファイルから選択する場合があります。さらに、専門家は、暗号化アルゴリズムの代替案をすべて指定する必要はありません。すべての可能な選択肢を指定しても、すべての実装でそれらすべてを利用できるわけではありません。実装必須アルゴリズムは、十分に研究された安定した公開仕様と公開ドキュメントを備えている必要があり、大きな信頼を生み出します。 IETFは常に、邪魔されないアルゴリズムを優先してきました。広く展開されているアルゴリズムとスイートを選択することには大きなメリットがあります。選択されたアルゴリズムは、サイドチャネル攻撃に耐性があり、さまざまなプラットフォームでのパフォーマンス、電力、およびコードサイズの要件を満たす必要があります。さらに、多すぎる選択肢を含めると、アルゴリズムの選択や交渉が複雑になる可能性があります。あまりにも多くの選択肢を指定すると、相互運用性が損なわれ、セキュリティも損なわれる可能性があります。新しいアルゴリズムまたはスイートを指定する場合、プロトコル設計者は、既存のアルゴリズムまたは非推奨のものを廃止できるかどうかを検討するのが賢明です。
There is significant benefit in selecting the same algorithms and suites for different protocols. Using the same algorithms can simplify implementation when more than one of the protocols is used in the same device or system.
異なるプロトコルに対して同じアルゴリズムとスイートを選択することには大きなメリットがあります。同じデバイスまたはシステムで複数のプロトコルが使用されている場合、同じアルゴリズムを使用すると、実装を簡素化できます。
Sometimes more than one mandatory-to-implement algorithm is needed to increase the likelihood of interoperability among a diverse population. For example, authenticated encryption is provided by AES-CCM [RFC3610] and AES-GCM [GCM]. Both of these algorithms are considered to be secure. AES-CCM is available in hardware used by many small devices, and AES-GCM is parallelizable and well suited to high-speed devices. Therefore, an application needing authenticated encryption might specify one of these algorithms or both of these algorithms, depending on the population.
多様な集団間の相互運用性の可能性を高めるために、複数の必須から実装までのアルゴリズムが必要になる場合があります。たとえば、認証された暗号化はAES-CCM [RFC3610]とAES-GCM [GCM]によって提供されます。これらのアルゴリズムはどちらも安全であると見なされています。 AES-CCMは、多くの小型デバイスで使用されるハードウェアで利用でき、AES-GCMは並列化可能で、高速デバイスに適しています。したがって、認証された暗号化を必要とするアプリケーションは、母集団に応じて、これらのアルゴリズムの一方または両方を指定する可能性があります。
It is fairly easy to specify the use of any arbitrary cryptographic algorithm, and once the specification is available, the algorithm gets implemented and deployed. Some people say that the freedom to specify algorithms independently from the rest of the protocol has led to the specification of too many cryptographic algorithms. Once deployed, even with moderate uptake, it is quite difficult to remove algorithms because interoperability with some party will be impacted. As a result, weaker ciphers stick around far too long. Sometimes implementers are forced to maintain cryptographic algorithm implementations well beyond their useful lifetime.
任意の暗号化アルゴリズムの使用を指定するのはかなり簡単で、仕様が利用可能になると、アルゴリズムが実装されて展開されます。一部の人々は、プロトコルの残りの部分から独立してアルゴリズムを指定する自由は、あまりにも多くの暗号アルゴリズムの仕様につながったと言います。いったん導入されると、ある程度の取り込みがあっても、一部のパーティとの相互運用性に影響が及ぶため、アルゴリズムを削除することは非常に困難です。その結果、より弱い暗号はあまりにも長く留まります。実装者は、暗号化アルゴリズムの実装をその有効寿命をはるかに超えて維持することを強いられることがあります。
In order to manage the proliferation of algorithm choices and provide an expectation of interoperability, many protocols specify mandatory-to-implement algorithms or suites. All implementers are expected to support the mandatory-to-implement cryptographic algorithm, and they can include any others algorithms that they desire. The mandatory-to-implement algorithms are chosen to be highly secure and follow the guidance in RFC 1984 [RFC1984]. Of course, many other factors, including intellectual property rights, have an impact on the cryptographic algorithms that are selected by the community. Generally, the mandatory-to-implement algorithms ought to be preferred, and the other algorithms ought to be selected only in special situations. However, it can be very difficult for a skilled system administrator to determine the proper configuration to achieve these preferences.
アルゴリズムの選択肢の急増を管理し、相互運用性の期待を提供するために、多くのプロトコルは、必須から実装までのアルゴリズムまたはスイートを指定しています。すべての実装者は、必須から実装までの暗号アルゴリズムをサポートすることが期待されており、必要な他のアルゴリズムを含めることができます。実装に必須のアルゴリズムは、安全性が高く、RFC 1984 [RFC1984]のガイダンスに従うように選択されています。もちろん、知的財産権を含む他の多くの要因は、コミュニティによって選択された暗号化アルゴリズムに影響を与えます。一般に、必須から実装までのアルゴリズムが優先され、他のアルゴリズムは特別な状況でのみ選択されるべきです。ただし、熟練したシステム管理者がこれらの設定を実現するための適切な構成を決定することは非常に困難です。
In some cases, more than one mandatory-to-implement cryptographic algorithm has been specified. This is intended to ensure that at least one secure cryptographic algorithm will be available, even if other mandatory-to-implement algorithms are broken. To achieve this goal, the selected algorithms must be diverse, so that a cryptoanalytic advance against one of the algorithms does not also impact the other selected algorithms. The idea is to have an implemented and deployed algorithm as a fallback. However, all of the selected algorithms need to be routinely exercised to ensure quality implementation. This is not always easy to do, especially if the various selected algorithms require different credentials. Obtaining multiple credentials for the same installation is an unacceptable burden on system administrators. Also, the manner by which system administrators are advised to switch algorithms or suites is, at best, ad hoc and, at worst, entirely absent.
場合によっては、実装に必須の暗号化アルゴリズムが複数指定されています。これは、他の必須の実装アルゴリズムが壊れている場合でも、少なくとも1つの安全な暗号化アルゴリズムが確実に使用できるようにすることを目的としています。この目標を達成するには、アルゴリズムの1つに対する暗号解読の進歩が他の選択されたアルゴリズムにも影響を与えないように、選択されたアルゴリズムは多様でなければなりません。アイデアは、フォールバックとして実装および展開されたアルゴリズムを持つことです。ただし、選択したすべてのアルゴリズムを定期的に実行して、高品質の実装を確保する必要があります。特に、選択されたさまざまなアルゴリズムが異なる資格情報を必要とする場合、これは必ずしも簡単ではありません。同じインストールで複数の資格情報を取得することは、システム管理者にとって許容できない負担になります。また、システム管理者がアルゴリズムまたはスイートを切り替えるように助言される方法は、せいぜいアドホックであり、最悪の場合、まったくありません。
In the past, protocol designers have chosen one cryptographic algorithm or suite, and then tied many protocol details to that selection. Plan for algorithm transition, either because a mistake is made in the initial selection or because the protocol is successfully used for a long time and the algorithm becomes weak with age. Either way, the design should enable transition.
これまで、プロトコル設計者は1つの暗号化アルゴリズムまたはスイートを選択し、その後、多くのプロトコルの詳細をその選択に結び付けていました。アルゴリズムの移行を計画します。最初の選択に誤りがあったか、プロトコルが長期間正常に使用されていて、アルゴリズムが古くなるにつれて弱くなるためです。どちらの方法でも、設計は移行を可能にする必要があります。
Protocol designers are sometimes misled by the simplicity that results from selecting one true algorithm or suite. Since algorithms age, the selection cannot be stable forever. Even the most simple protocol needs a version number to signal which algorithm is being used. This approach has at least two desirable consequences. First, the protocol is simpler because there is no need for algorithm negotiation. Second, system administrators do not need to make any algorithm-related configuration decisions. However, the only way to respond to news that an algorithm that is part of the one true cipher suite has been broken is to update the protocol specification to the next version, implement the new specification, and then get it deployed.
プロトコルの設計者は、1つの真のアルゴリズムまたはスイートを選択することで得られる単純さに迷惑をかけることがあります。アルゴリズムは古くなるため、選択は永久に安定することはできません。最も単純なプロトコルでも、使用されているアルゴリズムを通知するためにバージョン番号が必要です。このアプローチには、少なくとも2つの望ましい結果があります。まず、アルゴリズムのネゴシエーションが必要ないため、プロトコルが単純です。第2に、システム管理者はアルゴリズム関連の構成決定を行う必要がありません。ただし、1つの真の暗号スイートの一部であるアルゴリズムが壊れているというニュースに応答する唯一の方法は、プロトコル仕様を次のバージョンに更新し、新しい仕様を実装して、それを配備することです。
The first IEEE 802.11 [WiFi] specification included Wired Equivalent Privacy (WEP) as the only encryption technique. Many of the protocol details were driven by the selected algorithm. WEP was found to be quite weak [WEP], and a very large effort was needed to specify, implement, and deploy the alternative encryption techniques. This effort was made even harder by the protocol design choices that were tied to the initial algorithm selection and the desire for backward compatibility.
最初のIEEE 802.11 [WiFi]仕様には、唯一の暗号化技術としてWired Equivalent Privacy（WEP）が含まれていました。プロトコルの詳細の多くは、選択したアルゴリズムによって駆動されました。 WEPは非常に脆弱であることがわかり[WEP]、代替の暗号化技術を指定、実装、および展開するには非常に大きな労力が必要でした。この努力は、最初のアルゴリズムの選択と下位互換性の要望に結び付けられたプロトコル設計の選択によって、さらに困難になりました。
Experience with the transition from SHA-1 to SHA-256 indicates that the time from protocol specification to widespread use takes more than five years. In this case, the protocol specifications and implementation were straightforward and fairly prompt. In many software products, the new algorithm was not considered an update to the existing release, so the roll-out of the next release, subsequent deployment, and finally adjustment of the configuration by system administrators took many years. In many consumer hardware products, firmware to implement the new algorithm was difficult to locate and install, or it was simply not available. Further, infrastructure providers were unwilling to make the transition until all of their potential clients were able to use the new algorithm.
SHA-1からSHA-256への移行の経験から、プロトコルの仕様から普及までに5年以上かかることがわかります。この場合、プロトコルの仕様と実装は簡単で、かなり迅速でした。多くのソフトウェア製品では、新しいアルゴリズムは既存のリリースの更新とは見なされなかったため、次のリリースのロールアウト、その後の展開、および最終的にシステム管理者による構成の調整には何年もかかりました。多くのコンシューマ向けハードウェア製品では、新しいアルゴリズムを実装するファームウェアを見つけてインストールするのが困難であるか、単に利用できませんでした。さらに、インフラストラクチャプロバイダーは、すべての潜在的なクライアントが新しいアルゴリズムを使用できるようになるまで、移行を望んでいませんでした。
Some nations specify cryptographic algorithms, and then require their use through legislation or regulations. These algorithms may not have wide public review, and they can have limited geographic scope in their deployment. Yet, the legislative or regulatory mandate creates a captive market. As a result, such algorithms will get specified, implemented, and deployed. The default server or responder configuration SHOULD disable such algorithms; in this way, explicit action by the system administrator is needed to enable them where they are actually required. For tiny devices with no user interface, an administrator action may only be possible at the time the device is purchased.
一部の国では、暗号化アルゴリズムを指定してから、法律または規制を通じてそれらを使用する必要があります。これらのアルゴリズムは広く公開されていない可能性があり、展開の地理的範囲が制限される可能性があります。それでも、立法または規制の委任は捕虜の市場を作成します。その結果、そのようなアルゴリズムは指定、実装、および展開されます。デフォルトのサーバーまたはレスポンダー構成は、そのようなアルゴリズムを無効にする必要があります（SHOULD）。このように、実際に必要な場所でそれらを有効にするには、システム管理者による明示的なアクションが必要です。ユーザーインターフェイスのない小さなデバイスの場合、管理者の操作はデバイスの購入時にのみ可能です。
National algorithms can force an implementer to produce several incompatible product releases for different countries or regions; this has significantly greater cost over development of a product using a globally acceptable algorithm. This situation could be even worse if the various national algorithms impose different requirements on the protocol, its key management, or its use of random values.
国のアルゴリズムにより、実装者はさまざまな国または地域に対応しない複数の製品リリースを作成する必要があります。これは、グローバルに受け入れ可能なアルゴリズムを使用した製品の開発よりも大幅にコストが高くなります。さまざまな国のアルゴリズムがプロトコル、そのキー管理、またはランダム値の使用に異なる要件を課している場合、この状況はさらに悪化する可能性があります。
This document provides guidance to working groups and protocol designers. The security of the Internet is improved when broken or weak cryptographic algorithms can be easily replaced with strong ones.
このドキュメントは、ワーキンググループとプロトコル設計者へのガイダンスを提供します。壊れた、または弱い暗号アルゴリズムを強力なアルゴリズムに簡単に置き換えることができる場合、インターネットのセキュリティが向上します。
From a software development and maintenance perspective, cryptographic algorithms can often be added and removed without making changes to surrounding data structures, protocol parsing routines, or state machines. This approach separates the cryptographic algorithm implementation from the rest of the code, which makes it easier to tackle special security concerns such as key exposure and constant-time execution.
ソフトウェアの開発と保守の観点からは、暗号化アルゴリズムは、周囲のデータ構造、プロトコル解析ルーチン、またはステートマシンに変更を加えることなく追加および削除できることがよくあります。このアプローチは、暗号化アルゴリズムの実装を残りのコードから分離します。これにより、鍵の公開や一定時間の実行などの特別なセキュリティ問題への取り組みが容易になります。
Sometimes application-layer protocols can make use of transport-layer security protocols, such as TLS [RFC5246] or Datagram TLS (DTLS) [RFC6347]. This insulates the application-layer protocol from the details of cryptography, but it is likely to still be necessary to handle the transition from unprotected traffic to protected traffic in the application-layer protocol. In addition, the application-layer protocol may need to handle the downgrade from encrypted communication to plaintext communication.
アプリケーション層プロトコルは、TLS [RFC5246]やデータグラムTLS（DTLS）[RFC6347]などのトランスポート層セキュリティプロトコルを利用できる場合があります。これにより、アプリケーション層プロトコルは暗号化の詳細から隔離されますが、アプリケーション層プロトコルで保護されていないトラフィックから保護されたトラフィックへの移行を処理する必要がある可能性があります。さらに、アプリケーション層プロトコルは、暗号化通信からプレーンテキスト通信へのダウングレードを処理する必要がある場合があります。
Hardware offers challenges in the transition of algorithms, for both tiny devices and very high-end data center equipment. Many tiny devices do not include the ability to update the firmware at all. Even if the firmware can be updated, tiny devices are often deployed in places that make it very inconvenient to do so. High-end data center equipment may use special-purpose chips to achieve very high performance, which means that board-level replacement may be needed to change the algorithm. Cost and downtime are both factors in such an upgrade.
ハードウェアは、小さなデバイスと非常にハイエンドのデータセンター機器の両方で、アルゴリズムの移行に課題をもたらします。多くの小さなデバイスには、ファームウェアを更新する機能がまったく含まれていません。ファームウェアを更新できる場合でも、小さなデバイスが頻繁に展開され、更新が非常に不便になります。ハイエンドのデータセンター機器は、特別な目的のチップを使用して非常に高いパフォーマンスを実現する場合があります。つまり、アルゴリズムを変更するには、ボードレベルの交換が必要になる場合があります。コストとダウンタイムはどちらも、このようなアップグレードの要因です。
In most cases, the cryptographic algorithm remains strong, but an attack is found against the way that the strong algorithm is used in a particular protocol. In these cases, a protocol change will probably be needed. For example, the order of cryptographic operations in the TLS protocol has evolved as various attacks have been discovered. Originally, TLS performed encryption after computation of the message authentication code (MAC). This order of operations is called MAC-then-encrypt, which actually involves MAC computation, padding, and then encryption. This is no longer considered secure [BN] [K]. As a result, a mechanism was specified to use encrypt-then-MAC instead [RFC7366]. Future versions of TLS are expected to use exclusively authenticated encryption algorithms [RFC5116], which should resolve the ordering discussion altogether. After discovery of such attacks, updating the cryptographic algorithms is not likely to be sufficient to thwart the new attack. It may necessary to make significant changes to the protocol.
ほとんどの場合、暗号化アルゴリズムは強力なままですが、特定のプロトコルで強力なアルゴリズムが使用される方法に対する攻撃が見つかります。これらの場合、プロトコルの変更が必要になる可能性があります。たとえば、TLSプロトコルでの暗号化操作の順序は、さまざまな攻撃が発見されるにつれて進化しています。当初、TLSはメッセージ認証コード（MAC）の計算後に暗号化を実行しました。この操作の順序はMAC-then-encryptと呼ばれ、実際にはMACの計算、パディング、そして暗号化が含まれます。これは安全であるとは見なされなくなりました[BN] [K]。その結果、代わりに暗号化してからMACを使用するメカニズムが指定されました[RFC7366]。 TLSの将来のバージョンでは、認証の暗号化アルゴリズム[RFC5116]のみを使用することが期待されています。これにより、順序に関する議論がすべて解決されるはずです。そのような攻撃の発見後、暗号化アルゴリズムを更新するだけでは、新しい攻撃を阻止するのに十分ではない可能性があります。プロトコルに大幅な変更を加える必要がある場合があります。
Some protocols are used to protect stored data. For example, S/MIME [RFC5751] can protect a message kept in a mailbox. To recover the protected stored data, protocol implementations need to support older algorithms, even when they no longer use the older algorithms for the protection of new stored data.
保存されたデータを保護するためにいくつかのプロトコルが使用されます。たとえば、S / MIME [RFC5751]は、メールボックスに保持されているメッセージを保護できます。保護された保存データを回復するために、プロトコルの実装は、新しい保存データの保護に古いアルゴリズムを使用しなくなった場合でも、古いアルゴリズムをサポートする必要があります。
Support for too many algorithms can lead to implementation vulnerabilities. When many algorithms are supported, some of them will be rarely used. Any code that is rarely used can contain undetected bugs, and algorithm implementations are no different. Measurements SHOULD be used to determine whether implemented algorithms are actually being used, and if they are not, future releases should remove them. In addition, unused algorithms or suites SHOULD be marked as deprecated in the IANA registry. In short, eliminate the cruft.
アルゴリズムのサポートが多すぎると、実装の脆弱性につながる可能性があります。多くのアルゴリズムがサポートされている場合、それらのいくつかはほとんど使用されません。ほとんど使用されないコードには、検出されないバグが含まれる可能性があり、アルゴリズムの実装も同じです。測定は、実装されたアルゴリズムが実際に使用されているかどうかを判断するために使用されるべきであり、使用されていない場合、将来のリリースではそれらを削除する必要があります。さらに、未使用のアルゴリズムまたはスイートは、IANAレジストリで非推奨としてマークする必要があります（SHOULD）。要するに、残骸を排除します。
Section 2.3 talks about algorithm transition without considering any other aspects of the protocol design. In practice, there are dependencies between the cryptographic algorithm and other aspects of the protocol. For example, the BEAST attack [BEAST] against TLS [RFC5246] caused many sites to turn off modern cryptographic algorithms in favor of older and clearly weaker algorithms.
セクション2.3では、プロトコル設計の他の側面を考慮せずにアルゴリズムの移行について説明します。実際には、暗号アルゴリズムとプロトコルの他の側面の間には依存関係があります。たとえば、TLS [RFC5246]に対するBEAST攻撃[BEAST]により、多くのサイトでは、古くて明らかに弱いアルゴリズムを支持して、最新の暗号化アルゴリズムを無効にしました。
Mechanisms for timely update of devices are needed to deploy a replacement algorithm or suite. It takes a long time to specify, implement, and deploy a replacement; therefore, the transition process needs to begin when practically exploitable flaws become known. The update processes on some devices involve certification, which further increases the time to deploy a replacement. For example, devices that are part of health or safety systems often require certification before deployment. Embedded systems and SCADA (supervisory control and data acquisition) systems often have upgrade cycles stretching over many years, leading to similar time-to-deployment issues. Prompt action is needed if a replacement has any hope of being deployed before exploitation techniques become widely available.
置換アルゴリズムまたはスイートを展開するには、デバイスをタイムリーに更新するためのメカニズムが必要です。置換を指定、実装、および展開するには長い時間がかかります。したがって、移行プロセスは、実際に悪用可能な欠陥が判明したときに開始する必要があります。一部のデバイスの更新プロセスには認定が含まれているため、交換品を展開する時間がさらに長くなります。たとえば、健康または安全システムの一部であるデバイスは、展開前に認証を必要とすることがよくあります。組み込みシステムとSCADA（監視制御およびデータ取得）システムは、多くの場合、アップグレードサイクルが長年にわたっており、導入までの時間に同様の問題が発生しています。悪用手法が広く利用可能になる前に、代替品が展開される可能性がある場合は、迅速な対応が必要です。
This document does not establish any new IANA registries, nor does it add any entries to existing registries.
このドキュメントでは、新しいIANAレジストリを確立することも、既存のレジストリにエントリを追加することもありません。
This document does RECOMMEND a convention for new registries for cryptographic algorithm or suite identifiers. Once an algorithm or suite identifier is added to the registry, it SHOULD NOT be changed or removed. However, it is desirable to include a means of marking a registry entry as deprecated when implementation is no longer advisable.
このドキュメントでは、暗号化アルゴリズムまたはスイート識別子の新しいレジストリの規則を推奨しています。アルゴリズムまたはスイート識別子がレジストリに追加されたら、変更または削除してはなりません。ただし、実装が推奨されなくなった場合は、レジストリエントリを非推奨としてマークする手段を含めることが望ましいです。
[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>。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, DOI 10.17487/RFC3766, April 2004, <http://www.rfc-editor.org/info/rfc3766>.
[RFC3766] Orman、H。およびP. Hoffman、「Determining Strengths for Public Keys Exchangeing Symmetric Keys」、BCP 86、RFC 3766、DOI 10.17487 / RFC3766、2004年4月、<http：//www.rfc-editor。 org / info / rfc3766>。
[BEAST] Wikipedia, "BEAST attack" under "Transport Layer Security", November 2015, <https://en.wikipedia.org/w/index.php?title= Transport_Layer_Security&oldid=689441642#BEAST_attack>.
[BEAST]ウィキペディア、「トランスポート層セキュリティ」の下の「ビースト攻撃」、2015年11月、<https://en.wikipedia.org/w/index.php?title= Transport_Layer_Security＆oldid = 689441642＃BEAST_attack>。
[BN] Bellare, M. and C. Namprempre, "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm", Proceedings of AsiaCrypt '00, Springer-Verlag LNCS No. 1976, p. 531, DOI 10.1007/3-540-44448-3_41, December 2000.
[BN] Bellare、M。およびC. Namprempre、「Authenticated Encryption：Relations between notions and analysis of the generic composition paradigm」、Proceedings of AsiaCrypt '00、Springer-Verlag LNCS No. 1976、p。 531、DOI 10.1007 / 3-540-44448-3_41、2000年12月。
[GCM] Dworkin, M, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-30D, November 2007.
[GCM] Dworkin、M、「Block Cipher Modes of Operation：Galois / Counter Mode（GCM）and GMAC」、NIST Special Publication 800-30D、2007年11月。
[K] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?)", Proceedings of Crypto '01, Springer-Verlag LNCS No. 2139, p. 310, DOI 10.1007/3-540-44647-8_19, August 2001.
[K] Krawczyk、H。、「通信を保護するための暗号化と認証の順序（または：SSLの安全性は？）」、Crypto '01、Springer-Verlag LNCS No. 2139、p。 310、DOI 10.1007 / 3-540-44647-8_19、2001年8月。
[RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <http://www.rfc-editor.org/info/rfc1984>.
[RFC1984] IABおよびIESG、「暗号化技術およびインターネットに関するIABおよびIESGステートメント」、BCP 200、RFC 1984、DOI 10.17487 / RFC1984、1996年8月、<http://www.rfc-editor.org/info/rfc1984 >。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>.
[RFC3365] Schiller、J。、「Strong Security Requirements for Internet Engineering Task Force Standard Protocols」、BCP 61、RFC 3365、DOI 10.17487 / RFC3365、2002年8月、<http://www.rfc-editor.org/info/ rfc3365>。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <http://www.rfc-editor.org/info/rfc3610>.
[RFC3610] Whiting、D.、Housley、R。、およびN. Ferguson、「Counter with CBC-MAC（CCM）」、RFC 3610、DOI 10.17487 / RFC3610、2003年9月、<http：//www.rfc-editor .org / info / rfc3610>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、DOI 10.17487 / RFC3748、2004年6月、<http://www.rfc-editor.org/info/rfc3748>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.
[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<http://www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <http://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<http://www.rfc-editor.org/info/rfc4303>。
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, DOI 10.17487/RFC4307, December 2005, <http://www.rfc-editor.org/info/rfc4307>.
[RFC4307] Schiller、J。、「インターネットキーエクスチェンジバージョン2（IKEv2）で使用する暗号化アルゴリズム」、RFC 4307、DOI 10.17487 / RFC4307、2005年12月、<http://www.rfc-editor.org/info / rfc4307>。
[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。、編、およびK. Zeilenga、編、「Simple Authentication and Security Layer（SASL）」、RFC 4422、DOI 10.17487 / RFC4422、2006年6月、<http：//www.rfc- editor.org/info/rfc4422>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<http://www.rfc-editor.org/info/rfc5116>。
[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、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<http://www.rfc-editor.org/info/rfc5652>。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<http：//www.rfc- editor.org/info/rfc5751>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、DOI 10.17487 / RFC6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, <http://www.rfc-editor.org/info/rfc6916>.
[RFC6916]ガリアーノ、R。、ケント、S。、およびS.ターナー、「リソース公開鍵インフラストラクチャ（RPKI）のアルゴリズムの俊敏性手順」、BCP 182、RFC 6916、DOI 10.17487 / RFC6916、2013年4月、<http： //www.rfc-editor.org/info/rfc6916>。
[RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, <http://www.rfc-editor.org/info/rfc6975>.
[RFC6975] Crocker、S。およびS. Rose、「DNS Security Extensions（DNSSEC）での信号暗号化アルゴリズムの理解」、RFC 6975、DOI 10.17487 / RFC6975、2013年7月、<http://www.rfc-editor.org/ info / rfc6975>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, <http://www.rfc-editor.org/info/rfc7366>.
[RFC7366] Gutmann、P。、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の暗号化後MAC」、RFC 7366、DOI 10.17487 / RFC7366、2014年9月、<http：//www.rfc -editor.org/info/rfc7366>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[WEP] Wikipedia, "Wired Equivalent Privacy", November 2015, <https://en.wikipedia.org/w/index.php? title=Wired_Equivalent_Privacy&oldid=688848497>.
[WEP] Wikipedia、「Wired Equivalent Privacy」、2015年11月、<https://en.wikipedia.org/w/index.php？ title = Wired_Equivalent_Privacy＆oldid = 688848497>。
[WiFi] IEEE, "Wireless LAN Medium Access Control (MAC) And Physical Layer (PHY) Specifications", IEEE Std 802.11-1997, 1997.
[WiFi] IEEE、「ワイヤレスLANメディアアクセスコントロール（MAC）および物理層（PHY）仕様」、IEEE Std 802.11-1997、1997。
Acknowledgements
謝辞
Thanks to Bernard Aboba, Derek Atkins, David Black, Randy Bush, Jon Callas, Andrew Chi, Steve Crocker, Viktor Dukhovni, Stephen Farrell, Tony Finch, Ian Grigg, Peter Gutmann, Phillip Hallam-Baker, Wes Hardaker, Joe Hildebrand, Paul Hoffman, Christian Huitema, Leif Johansson, Suresh Krishnan, Watson Ladd, Paul Lambert, Ben Laurie, Eliot Lear, Nikos Mavrogiannopoulos, Kathleen Moriarty, Yoav Nir, Kenny Paterson, Rich Salz, Wendy Seltzer, Joel Sing, Rene Struik, Kristof Teichel, Martin Thompson, Jeffrey Walton, Nico Williams, and Peter Yee for their review and insightful comments. While some of these people do not agree with some aspects of this document, the discussion that resulted for their comments has certainly resulted in a better document.
Bernard Aboba、Derek Atkins、David Black、Randy Bush、Jon Callas、Andrew Chi、Steve Crocker、Viktor Dukhovni、Stephen Farrell、Tony Finch、Ian Grigg、Peter Gutmann、Phillip Hallam-Baker、Wes Hardaker、Joe Hildebrand、Paulのおかげでホフマン、クリスチャンウイテマ、レイフヨハンソン、スレーシュクリシュナン、ワトソンラッド、ポールランバート、ベンローリー、エリオットリア、ニコスマブロジアンノプロス、キャスリーンモリアーティー、ヨアフニル、ケニーパターソン、リッチサルツ、ウェンディセルツァー、ジョエルシング、ルネストルイケルマーティン・トンプソン、ジェフリー・ウォルトン、ニコ・ウィリアムズ、ピーター・イーのレビューと洞察に満ちたコメント。これらの人々の一部はこのドキュメントのいくつかの側面に同意しませんが、彼らのコメントのために生じた議論は確かにより良いドキュメントをもたらしました。
Author's Address
著者のアドレス
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States
Russ Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ
Email: housley@vigilsec.com