[要約] RFC 7525は、Transport Layer Security (TLS) および Datagram Transport Layer Security (DTLS) の安全な使用に関する推奨事項を提供します。この文書の目的は、インターネット上でのデータの安全な伝送を強化するためのベストプラクティスと構成ガイドラインを提供することです。利用場面には、ウェブブラウジング、電子メール、インスタントメッセージング、およびその他の形式の通信が含まれます。関連するRFCには、RFC 5246（TLS 1.2の仕様）、RFC 6347（DTLS 1.2の仕様）、およびRFC 8446（TLS 1.3の仕様）などがあります。RFC 7525は、これらのプロトコルをより安全に実装し、運用するための具体的なアドバイスを提供します。
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 7525 Intuit
BCP: 195 R. Holz
Category: Best Current Practice NICTA
ISSN: 2070-1721 P. Saint-Andre
&yet
May 2015
Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の安全な使用に関する推奨事項
Abstract
概要
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.
トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）は、HTTP、SMTP、IMAP、POP、SIP、XMPPなどのアプリケーションプロトコルを介して交換されるデータを保護するために広く使用されています。過去数年間で、最も一般的に使用されている暗号スイートとその動作モードへの攻撃を含む、TLSに対する深刻な攻撃がいくつか出現しています。このドキュメントでは、TLSとDTLSを使用するデプロイされたサービスのセキュリティを向上させるための推奨事項を提供します。推奨事項は、ほとんどのユースケースに適用できます。
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/rfc7525.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7525で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General Recommendations . . . . . . . . . . . . . . . . . . . 5
3.1. Protocol Versions . . . . . . . . . . . . . . . . . . . . 5
3.1.1. SSL/TLS Protocol Versions . . . . . . . . . . . . . . 5
3.1.2. DTLS Protocol Versions . . . . . . . . . . . . . . . 6
3.1.3. Fallback to Lower Versions . . . . . . . . . . . . . 7
3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. TLS Session Resumption . . . . . . . . . . . . . . . . . 8
3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . . . . 9
3.6. Server Name Indication . . . . . . . . . . . . . . . . . 9
4. Recommendations: Cipher Suites . . . . . . . . . . . . . . . 9
4.1. General Guidelines . . . . . . . . . . . . . . . . . . . 9
4.2. Recommended Cipher Suites . . . . . . . . . . . . . . . . 11
4.2.1. Implementation Details . . . . . . . . . . . . . . . 12
4.3. Public Key Length . . . . . . . . . . . . . . . . . . . . 12
4.4. Modular Exponential vs. Elliptic Curve DH Cipher Suites . 13
4.5. Truncated HMAC . . . . . . . . . . . . . . . . . . . . . 14
5. Applicability Statement . . . . . . . . . . . . . . . . . . . 15
5.1. Security Services . . . . . . . . . . . . . . . . . . . . 15
5.2. Opportunistic Security . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6.1. Host Name Validation . . . . . . . . . . . . . . . . . . 17
6.2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 18
6.4. Diffie-Hellman Exponent Reuse . . . . . . . . . . . . . . 19
6.5. Certificate Revocation . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
Transport Layer Security (TLS) [RFC5246] and Datagram Transport Security Layer (DTLS) [RFC6347] are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. For instance, both the AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms, which together have been the most widely deployed ciphers, have been attacked in the context of TLS. A companion document [RFC7457] provides detailed information about these attacks and will help the reader understand the rationale behind the recommendations provided here.
トランスポート層セキュリティ（TLS）[RFC5246]およびデータグラムトランスポートセキュリティ層（DTLS）[RFC6347]は、HTTP、SMTP、IMAP、POP、SIP、XMPPなどのアプリケーションプロトコルを介して交換されるデータを保護するために広く使用されています。過去数年間で、最も一般的に使用されている暗号スイートとその動作モードへの攻撃を含む、TLSに対する深刻な攻撃がいくつか出現しています。たとえば、AES-CBC [RFC3602]とRC4 [RFC7465]の両方の暗号化アルゴリズムは、共に最も広く導入されている暗号であり、TLSのコンテキストで攻撃されています。関連ドキュメント[RFC7457]はこれらの攻撃に関する詳細情報を提供し、読者がここで提供される推奨事項の根拠を理解するのに役立ちます。
Because of these attacks, those who implement and deploy TLS and DTLS need updated guidance on how TLS can be used securely. This document provides guidance for deployed services as well as for software implementations, assuming the implementer expects his or her code to be deployed in environments defined in Section 5. In fact, this document calls for the deployment of algorithms that are widely implemented but not yet widely deployed. Concerning deployment, this document targets a wide audience -- namely, all deployers who wish to add authentication (be it one-way only or mutual), confidentiality, and data integrity protection to their communications.
これらの攻撃のために、TLSとDTLSを実装および展開するユーザーは、TLSを安全に使用する方法に関する最新のガイダンスが必要です。このドキュメントは、実装されたサービスとソフトウェアの実装に関するガイダンスを提供します。ただし、実装者は、コードがセクション5で定義された環境にデプロイされることを期待していると想定しています。実際、このドキュメントでは、広く実装されているがまだ実装されていないアルゴリズムのデプロイが必要です。広く展開されています。導入に関しては、このドキュメントは幅広いオーディエンスを対象としています。つまり、認証（一方向のみまたは相互）、機密性、およびデータ整合性保護を通信に追加したいすべての導入者です。
The recommendations herein take into consideration the security of various mechanisms, their technical maturity and interoperability, and their prevalence in implementations at the time of writing. Unless it is explicitly called out that a recommendation applies to TLS alone or to DTLS alone, each recommendation applies to both TLS and DTLS.
ここでの推奨事項は、さまざまなメカニズムのセキュリティ、それらの技術的な成熟度と相互運用性、および執筆時点での実装におけるその普及を考慮に入れています。推奨事項がTLSのみまたはDTLSのみに適用されることが明示的に宣言されていない限り、各推奨事項はTLSとDTLSの両方に適用されます。
It is expected that the TLS 1.3 specification will resolve many of the vulnerabilities listed in this document. A system that deploys TLS 1.3 should have fewer vulnerabilities than TLS 1.2 or below. This document is likely to be updated after TLS 1.3 gets noticeable deployment.
TLS 1.3仕様は、このドキュメントにリストされている脆弱性の多くを解決することが期待されています。 TLS 1.3を導入するシステムは、TLS 1.2以下よりも脆弱性が少ないはずです。このドキュメントは、TLS 1.3が注目に値する展開を取得した後に更新される可能性があります。
These are minimum recommendations for the use of TLS in the vast majority of implementation and deployment scenarios, with the exception of unauthenticated TLS (see Section 5). Other specifications that reference this document can have stricter requirements related to one or more aspects of the protocol, based on their particular circumstances (e.g., for use with a particular application protocol); when that is the case, implementers are advised to adhere to those stricter requirements. Furthermore, this document provides a floor, not a ceiling, so stronger options are always allowed (e.g., depending on differing evaluations of the importance of cryptographic strength vs. computational load).
これらは、認証されていないTLSを除いて、大部分の実装および展開シナリオでのTLSの使用に関する最小推奨事項です（セクション5を参照）。このドキュメントを参照する他の仕様には、特定の状況に基づいて（たとえば、特定のアプリケーションプロトコルで使用するために）、プロトコルの1つ以上の側面に関連するより厳しい要件がある場合があります。その場合、実装者はこれらのより厳しい要件に準拠することをお勧めします。さらに、このドキュメントは上限ではなく下限を提供するため、より強力なオプションが常に許可されます（たとえば、暗号強度と計算負荷の重要性の異なる評価に応じて）。
Community knowledge about the strength of various algorithms and feasible attacks can change quickly, and experience shows that a Best Current Practice (BCP) document about security is a point-in-time statement. Readers are advised to seek out any errata or updates that apply to this document.
さまざまなアルゴリズムと実行可能な攻撃の強さに関するコミュニティの知識は急速に変化する可能性があり、経験から、セキュリティに関するベストカレントプラクティス（BCP）ドキュメントは特定時点のステートメントであることが示されています。読者は、このドキュメントに適用される正誤表または更新を探すことをお勧めします。
A number of security-related terms in this document are used in the sense defined in [RFC4949].
このドキュメントのセキュリティ関連の用語の多くは、[RFC4949]で定義されている意味で使用されています。
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]で説明されているように解釈されます。
This section provides general recommendations on the secure use of TLS. Recommendations related to cipher suites are discussed in the following section.
このセクションでは、TLSの安全な使用に関する一般的な推奨事項を示します。暗号スイートに関連する推奨事項については、次のセクションで説明します。
It is important both to stop using old, less secure versions of SSL/ TLS and to start using modern, more secure versions; therefore, the following are the recommendations concerning TLS/SSL protocol versions:
SSL / TLSの古い安全性の低いバージョンの使用を停止することと、最新の安全性の高いバージョンの使用を開始することが重要です。したがって、以下はTLS / SSLプロトコルのバージョンに関する推奨事項です。
o Implementations MUST NOT negotiate SSL version 2.
o 実装はSSLバージョン2をネゴシエートしてはなりません。
Rationale: Today, SSLv2 is considered insecure [RFC6176].
理論的根拠：今日、SSLv2は安全ではないと見なされています[RFC6176]。
o Implementations MUST NOT negotiate SSL version 3.
o 実装はSSLバージョン3をネゴシエートしてはなりません。
Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and plugged some significant security holes but did not support strong cipher suites. SSLv3 does not support TLS extensions, some of which (e.g., renegotiation_info [RFC5746]) are security-critical. In addition, with the emergence of the POODLE attack [POODLE], SSLv3 is now widely recognized as fundamentally insecure. See [DEP-SSLv3] for further details.
理論的根拠：SSLv3 [RFC6101]はSSLv2の改善であり、いくつかの重要なセキュリティホールを塞いだが、強力な暗号スイートをサポートしていなかった。 SSLv3はTLS拡張をサポートしていません。その一部（たとえば、renegotiation_info [RFC5746]）はセキュリティ上重要です。さらに、POODLE攻撃[POODLE]の出現により、SSLv3は根本的に安全ではないと広く認識されています。詳細については、[DEP-SSLv3]を参照してください。
o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]; the only exception is when no higher version is available in the negotiation.
o 実装はTLSバージョン1.0 [RFC2246]をネゴシエートしないでください。唯一の例外は、交渉でより高いバージョンが使用できない場合です。
Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per-record Initialization Vector (IV) for CBC-based cipher suites and does not warn against common padding errors.
理論的根拠：TLS 1.0（1999年に公開）は、多くの最新の強力な暗号スイートをサポートしていません。さらに、TLS 1.0には、CBCベースの暗号スイートのレコードごとの初期化ベクトル（IV）がなく、一般的なパディングエラーに対して警告しません。
o Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346]; the only exception is when no higher version is available in the negotiation.
o 実装はTLSバージョン1.1 [RFC4346]をネゴシエートしないでください。唯一の例外は、交渉でより高いバージョンが使用できない場合です。
Rationale: TLS 1.1 (published in 2006) is a security improvement over TLS 1.0 but still does not support certain stronger cipher suites.
理論的根拠：TLS 1.1（2006年に公開）はTLS 1.0よりもセキュリティが強化されていますが、特定の強力な暗号スイートはまだサポートされていません。
o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS.
o 実装はTLS 1.2 [RFC5246]をサポートしなければならず（MUST）、以前のバージョンのTLSよりもTLSバージョン1.2のネゴシエーションを好む必要があります。
Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008). In fact, the cipher suites recommended by this document (Section 4.2 below) are only available in TLS 1.2.
理論的根拠：いくつかの強力な暗号スイートは、TLS 1.2（2008年に公開）でのみ使用できます。実際、このドキュメントで推奨されている暗号スイート（以下のセクション4.2）は、TLS 1.2でのみ使用できます。
This BCP applies to TLS 1.2 and also to earlier versions. It is not safe for readers to assume that the recommendations in this BCP apply to any future version of TLS.
このBCPは、TLS 1.2および以前のバージョンにも適用されます。このBCPの推奨事項がTLSの将来のバージョンに適用されると読者が考えるのは安全ではありません。
DTLS, an adaptation of TLS for UDP datagrams, was introduced when TLS 1.1 was published. The following are the recommendations with respect to DTLS:
UDPデータグラム用のTLSの適応であるDTLSは、TLS 1.1が公開されたときに導入されました。 DTLSに関する推奨事項は次のとおりです。
o Implementations SHOULD NOT negotiate DTLS version 1.0 [RFC4347].
o 実装では、DTLSバージョン1.0 [RFC4347]をネゴシエートしないでください。
Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).
DTLSのバージョン1.0は、TLSのバージョン1.1に対応しています（上記を参照）。
o Implementations MUST support and MUST prefer to negotiate DTLS version 1.2 [RFC6347].
o 実装はサポートしなければならず、DTLSバージョン1.2 [RFC6347]のネゴシエーションを好む必要があります。
Version 1.2 of DTLS correlates to version 1.2 of TLS (see above). (There is no version 1.1 of DTLS.)
DTLSのバージョン1.2は、TLSのバージョン1.2と相関しています（上記を参照）。 （DTLSのバージョン1.1はありません。）
Clients that "fall back" to lower versions of the protocol after the server rejects higher versions of the protocol MUST NOT fall back to SSLv3 or earlier.
サーバーがプロトコルの上位バージョンを拒否した後、プロトコルの下位バージョンに「フォールバック」するクライアントは、SSLv3以前にフォールバックしてはなりません。
Rationale: Some client implementations revert to lower versions of TLS or even to SSLv3 if the server rejected higher versions of the protocol. This fallback can be forced by a man-in-the-middle (MITM) attacker. TLS 1.0 and SSLv3 are significantly less secure than TLS 1.2, the version recommended by this document. While TLS 1.0-only servers are still quite common, IP scans show that SSLv3-only servers amount to only about 3% of the current Web server population. (At the time of this writing, an explicit method for preventing downgrade attacks has been defined recently in [RFC7507].)
理論的根拠：一部のクライアント実装は、サーバーの上位バージョンのプロトコルを拒否した場合、下位バージョンのTLSまたはSSLv3に戻ります。このフォールバックは、中間者（MITM）攻撃者によって強制される可能性があります。 TLS 1.0とSSLv3は、このドキュメントで推奨されているバージョンであるTLS 1.2よりも安全性が大幅に低下します。 TLS 1.0のみのサーバーはまだかなり一般的ですが、IPスキャンでは、SSLv3のみのサーバーは現在のWebサーバーの人口の約3％にすぎないことが示されています。 （これを書いている時点で、ダウングレード攻撃を防ぐための明示的な方法が最近[RFC7507]で定義されています。）
The following recommendations are provided to help prevent SSL Stripping (an attack that is summarized in Section 2.1 of [RFC7457]):
SSLストリッピング（[RFC7457]のセクション2.1に要約されている攻撃）を防ぐために、次の推奨事項が提供されています。
o In cases where an application protocol allows implementations or deployments a choice between strict TLS configuration and dynamic upgrade from unencrypted to TLS-protected traffic (such as STARTTLS), clients and servers SHOULD prefer strict TLS configuration.
o アプリケーションプロトコルが実装またはデプロイメントで、厳密なTLS構成と、暗号化されていないトラフィックからTLSで保護されたトラフィック（STARTTLSなど）への動的アップグレードのどちらかを選択できる場合、クライアントとサーバーは、厳密なTLS構成を優先する必要があります。
o Application protocols typically provide a way for the server to offer TLS during an initial protocol exchange, and sometimes also provide a way for the server to advertise support for TLS (e.g., through a flag indicating that TLS is required); unfortunately, these indications are sent before the communication channel is encrypted. A client SHOULD attempt to negotiate TLS even if these indications are not communicated by the server.
o アプリケーションプロトコルは通常、初期プロトコル交換中にサーバーがTLSを提供する方法を提供し、サーバーがTLSのサポートをアドバタイズする方法を提供することもあります（たとえば、TLSが必要であることを示すフラグを通じて）。残念ながら、これらの表示は通信チャネルが暗号化される前に送信されます。これらの表示がサーバーによって伝達されない場合でも、クライアントはTLSのネゴシエーションを試みる必要があります（SHOULD）。
o HTTP client and server implementations MUST support the HTTP Strict Transport Security (HSTS) header [RFC6797], in order to allow Web servers to advertise that they are willing to accept TLS-only clients.
o HTTPクライアントとサーバーの実装は、WebサーバーがTLSのみのクライアントを受け入れる意思があることを通知できるようにするために、HTTP Strict Transport Security（HSTS）ヘッダー[RFC6797]をサポートする必要があります。
o Web servers SHOULD use HSTS to indicate that they are willing to accept TLS-only clients, unless they are deployed in such a way that using HSTS would in fact weaken overall security (e.g., it can be problematic to use HSTS with self-signed certificates, as described in Section 11.3 of [RFC6797]).
o Webサーバーは、HSTSを使用して実際に全体的なセキュリティを弱めるような方法で展開しない限り、HSTSを使用してTLSのみのクライアントを受け入れる用意があることを示す必要があります（たとえば、自己署名証明書でHSTSを使用すると問題が発生する可能性があります） 、[RFC6797]のセクション11.3に記載）。
Rationale: Combining unprotected and TLS-protected communication opens the way to SSL Stripping and similar attacks, since an initial part of the communication is not integrity protected and therefore can be manipulated by an attacker whose goal is to keep the communication in the clear.
理論的根拠：保護されていない通信とTLSで保護された通信を組み合わせることで、SSLストリッピングや同様の攻撃への道が開かれます。
In order to help prevent compression-related attacks (summarized in Section 2.6 of [RFC7457]), implementations and deployments SHOULD disable TLS-level compression (Section 6.2.2 of [RFC5246]), unless the application protocol in question has been shown not to be open to such attacks.
圧縮関連の攻撃（[RFC7457]のセクション2.6に要約）を防止するために、問題のアプリケーションプロトコルが示されていない場合を除き、実装と展開ではTLSレベルの圧縮（[RFC5246]のセクション6.2.2）を無効にする必要があります（SHOULD）。そのような攻撃に対してオープンであること。
Rationale: TLS compression has been subject to security attacks, such as the CRIME attack.
理論的根拠：TLS圧縮は、CRIME攻撃などのセキュリティ攻撃を受けやすい。
Implementers should note that compression at higher protocol levels can allow an active attacker to extract cleartext information from the connection. The BREACH attack is one such case. These issues can only be mitigated outside of TLS and are thus outside the scope of this document. See Section 2.6 of [RFC7457] for further details.
実装者は、より高いプロトコルレベルでの圧縮により、アクティブな攻撃者が接続からクリアテキスト情報を抽出できるようになることに注意する必要があります。 BREACH攻撃はそのようなケースの1つです。これらの問題はTLSの外部でのみ軽減できるため、このドキュメントの範囲外です。詳細については、[RFC7457]のセクション2.6を参照してください。
If TLS session resumption is used, care ought to be taken to do so safely. In particular, when using session tickets [RFC5077], the resumption information MUST be authenticated and encrypted to prevent modification or eavesdropping by an attacker. Further recommendations apply to session tickets:
TLSセッション再開を使用する場合は、安全に再開するように注意する必要があります。特に、セッションチケット[RFC5077]を使用する場合、攻撃者による変更または盗聴を防ぐために、再開情報を認証および暗号化する必要があります。セッションチケットには、さらに推奨事項が適用されます。
o A strong cipher suite MUST be used when encrypting the ticket (as least as strong as the main TLS cipher suite).
o チケットを暗号化するときは、強力な暗号スイートを使用する必要があります（少なくともメインのTLS暗号スイートと同じくらい強力です）。
o Ticket keys MUST be changed regularly, e.g., once every week, so as not to negate the benefits of forward secrecy (see Section 6.3 for details on forward secrecy).
o 転送秘密の利点を損なわないように、チケットの鍵は定期的、たとえば毎週1回変更する必要があります（転送秘密の詳細については、セクション6.3を参照してください）。
o For similar reasons, session ticket validity SHOULD be limited to a reasonable duration (e.g., half as long as ticket key validity).
o 同様の理由で、セッションチケットの有効期間は、妥当な期間（チケットキーの有効期間の半分など）に制限する必要があります（SHOULD）。
Rationale: session resumption is another kind of TLS handshake, and therefore must be as secure as the initial handshake. This document (Section 4) recommends the use of cipher suites that provide forward secrecy, i.e. that prevent an attacker who gains momentary access to the TLS endpoint (either client or server) and its secrets from reading either past or future communication. The tickets must be managed so as not to negate this security property.
理論的根拠：セッションの再開は別の種類のTLSハンドシェイクであるため、最初のハンドシェイクと同じくらい安全でなければなりません。このドキュメント（セクション4）では、フォワード秘匿性を提供する、つまりTLSエンドポイント（クライアントまたはサーバーのいずれか）とそのシークレットに瞬間的にアクセスする攻撃者が過去または将来の通信を読み取ることを防ぐ暗号スイートの使用を推奨しています。このセキュリティプロパティを無効にしないようにチケットを管理する必要があります。
Where handshake renegotiation is implemented, both clients and servers MUST implement the renegotiation_info extension, as defined in [RFC5746].
ハンドシェイク再ネゴシエーションが実装されている場合、[RFC5746]で定義されているように、クライアントとサーバーの両方がrenegotiation_info拡張を実装する必要があります。
The most secure option for countering the Triple Handshake attack is to refuse any change of certificates during renegotiation. In addition, TLS clients SHOULD apply the same validation policy for all certificates received over a connection. The [triple-handshake] document suggests several other possible countermeasures, such as binding the master secret to the full handshake (see [SESSION-HASH]) and binding the abbreviated session resumption handshake to the original full handshake. Although the latter two techniques are still under development and thus do not qualify as current practices, those who implement and deploy TLS are advised to watch for further development of appropriate countermeasures.
トリプルハンドシェイク攻撃に対抗するための最も安全なオプションは、再ネゴシエーション中の証明書の変更を拒否することです。さらに、TLSクライアントは、接続を介して受信したすべての証明書に同じ検証ポリシーを適用する必要があります（SHOULD）。 [トリプルハンドシェイク]ドキュメントは、マスターシークレットをフルハンドシェイクにバインドする（[SESSION-HASH]を参照）、短縮セッション再開ハンドシェイクを元のフルハンドシェイクにバインドするなど、他のいくつかの可能な対策を提案します。後者の2つの手法はまだ開発中であるため、現在のプラクティスとしての資格はありませんが、TLSを実装して展開する場合は、適切な対策のさらなる開発に注意することをお勧めします。
TLS implementations MUST support the Server Name Indication (SNI) extension defined in Section 3 of [RFC6066] for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy.
TLSの実装は、[RFC6066]のセクション3で定義されているサーバー名表示（SNI）拡張をサポートする必要があります。これは、HTTPSを含む、それから恩恵を受けるより高いレベルのプロトコルです。ただし、特定の状況でのSNIの実際の使用は、ローカルポリシーの問題です。
Rationale: SNI supports deployment of multiple TLS-protected virtual servers on a single address, and therefore enables fine-grained security for these virtual servers, by allowing each one to have its own certificate.
理論的根拠：SNIは、単一のアドレスでのTLSで保護された複数の仮想サーバーの展開をサポートしているため、各仮想サーバーが独自の証明書を持つことを許可することにより、これらの仮想サーバーのきめ細かなセキュリティを実現します。
TLS and its implementations provide considerable flexibility in the selection of cipher suites. Unfortunately, some available cipher suites are insecure, some do not provide the targeted security services, and some no longer provide enough security. Incorrectly configuring a server leads to no or reduced security. This section includes recommendations on the selection and negotiation of cipher suites.
TLSとその実装は、暗号スイートの選択にかなりの柔軟性を提供します。残念ながら、利用可能な暗号スイートの中には安全でないものや、対象のセキュリティサービスを提供していないもの、十分なセキュリティを提供していないものがあります。サーバーを誤って構成すると、セキュリティが失われるか、セキュリティが低下します。このセクションには、暗号スイートの選択とネゴシエーションに関する推奨事項が含まれています。
Cryptographic algorithms weaken over time as cryptanalysis improves: algorithms that were once considered strong become weak. Such algorithms need to be phased out over time and replaced with more secure cipher suites. This helps to ensure that the desired security properties still hold. SSL/TLS has been in existence for almost 20 years and many of the cipher suites that have been recommended in various versions of SSL/TLS are now considered weak or at least not as strong as desired. Therefore, this section modernizes the recommendations concerning cipher suite selection.
暗号解読が改善されるにつれて、暗号化アルゴリズムは時間とともに弱まります。かつて強力であると考えられていたアルゴリズムは弱くなります。このようなアルゴリズムは、時間をかけて段階的に廃止し、より安全な暗号スイートに置き換える必要があります。これにより、必要なセキュリティプロパティが引き続き保持されるようになります。 SSL / TLSは約20年前から存在しており、SSL / TLSのさまざまなバージョンで推奨されている暗号スイートの多くは、現在、弱いか、少なくとも必要以上に強くないと考えられています。したがって、このセクションでは、暗号スイートの選択に関する推奨事項を最新化します。
o Implementations MUST NOT negotiate the cipher suites with NULL encryption.
o 実装は、NULL暗号化を使用して暗号スイートをネゴシエートしてはなりません（MUST NOT）。
Rationale: The NULL cipher suites do not encrypt traffic and so provide no confidentiality services. Any entity in the network with access to the connection can view the plaintext of contents being exchanged by the client and server. (Nevertheless, this document does not discourage software from implementing NULL cipher suites, since they can be useful for testing and debugging.)
理論的根拠：NULL暗号スイートはトラフィックを暗号化しないため、機密性サービスは提供されません。接続にアクセスできるネットワーク内のすべてのエンティティは、クライアントとサーバーによって交換されているコンテンツのプレーンテキストを表示できます。 （それでも、このドキュメントは、テストとデバッグに役立つため、ソフトウェアがNULL暗号スイートを実装することを妨げません。）
o Implementations MUST NOT negotiate RC4 cipher suites.
o 実装は、RC4暗号スイートをネゴシエートしてはなりません（MUST NOT）。
Rationale: The RC4 stream cipher has a variety of cryptographic weaknesses, as documented in [RFC7465]. Note that DTLS specifically forbids the use of RC4 already.
理論的根拠：[RFC7465]で文書化されているように、RC4ストリーム暗号にはさまざまな暗号の弱点があります。 DTLSは特にRC4の使用をすでに禁止していることに注意してください。
o Implementations MUST NOT negotiate cipher suites offering less than 112 bits of security, including so-called "export-level" encryption (which provide 40 or 56 bits of security).
o 実装は、いわゆる「エクスポートレベル」の暗号化（40または56ビットのセキュリティを提供）を含む、112ビット未満のセキュリティを提供する暗号スイートをネゴシエートしてはなりません（MUST NOT）。
Rationale: Based on [RFC3766], at least 112 bits of security is needed. 40-bit and 56-bit security are considered insecure today. TLS 1.1 and 1.2 never negotiate 40-bit or 56-bit export ciphers.
根拠：[RFC3766]に基づいて、少なくとも112ビットのセキュリティが必要です。現在、40ビットおよび56ビットのセキュリティは安全ではないと考えられています。 TLS 1.1および1.2は、40ビットまたは56ビットのエクスポート暗号をネゴシエートすることはありません。
o Implementations SHOULD NOT negotiate cipher suites that use algorithms offering less than 128 bits of security.
o 実装では、128ビット未満のセキュリティを提供するアルゴリズムを使用する暗号スイートをネゴシエートしないでください。
Rationale: Cipher suites that offer between 112-bits and 128-bits of security are not considered weak at this time; however, it is expected that their useful lifespan is short enough to justify supporting stronger cipher suites at this time. 128-bit ciphers are expected to remain secure for at least several years, and 256-bit ciphers until the next fundamental technology breakthrough. Note that, because of so-called "meet-in-the-middle" attacks [Multiple-Encryption], some legacy cipher suites (e.g., 168-bit 3DES) have an effective key length that is smaller than their nominal key length (112 bits in the case of 3DES). Such cipher suites should be evaluated according to their effective key length.
理論的根拠：112ビットから128ビットのセキュリティを提供する暗号スイートは、現時点では脆弱とは見なされていません。しかし、それらの有効寿命は、現時点でより強力な暗号スイートをサポートすることを正当化するのに十分短いと予想されます。 128ビット暗号は少なくとも数年間は安全なままであり、256ビット暗号は次の基本的な技術の進歩が見つかるまで続くと予想されます。いわゆる「ミートインザミドル」攻撃[Multiple-Encryption]により、一部のレガシー暗号スイート（168ビット3DESなど）の有効キー長は、公称キー長（ 3DESの場合は112ビット）。このような暗号スイートは、有効なキーの長さに従って評価する必要があります。
o Implementations SHOULD NOT negotiate cipher suites based on RSA key transport, a.k.a. "static RSA".
o 実装は、RSAキートランスポート（別名「静的RSA」）に基づいて暗号スイートをネゴシエートしないでください。
Rationale: These cipher suites, which have assigned values starting with the string "TLS_RSA_WITH_*", have several drawbacks, especially the fact that they do not support forward secrecy.
理論的根拠：「TLS_RSA_WITH_ *」という文字列で始まる値が割り当てられているこれらの暗号スイートには、いくつかの欠点があります。特に、フォワードシークレシーをサポートしていないという事実があります。
o Implementations MUST support and prefer to negotiate cipher suites offering forward secrecy, such as those in the Ephemeral Diffie-Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and "ECDHE") families.
o 実装は、一時的なDiffie-Hellmanや楕円曲線の一時的なDiffie-Hellman（ "DHE"および "ECDHE"）ファミリなどの、前方秘匿性を提供する暗号スイートをサポートおよび交渉する必要があります。
Rationale: Forward secrecy (sometimes called "perfect forward secrecy") prevents the recovery of information that was encrypted with older session keys, thus limiting the amount of time during which attacks can be successful. See Section 6.3 for a detailed discussion.
理論的根拠：転送秘密（「完全転送秘密」と呼ばれることもあります）は、古いセッションキーで暗号化された情報の回復を防ぎ、攻撃が成功する時間を制限します。詳細については、セクション6.3を参照してください。
Given the foregoing considerations, implementation and deployment of the following cipher suites is RECOMMENDED:
前述の考慮事項を踏まえて、次の暗号スイートの実装と展開をお勧めします。
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
These cipher suites are supported only in TLS 1.2 because they are authenticated encryption (AEAD) algorithms [RFC5116].
これらの暗号スイートは、認証された暗号化（AEAD）アルゴリズム[RFC5116]であるため、TLS 1.2でのみサポートされます。
Typically, in order to prefer these suites, the order of suites needs to be explicitly configured in server software. (See [BETTERCRYPTO] for helpful deployment guidelines, but note that its recommendations differ from the current document in some details.) It would be ideal if server software implementations were to prefer these suites by default.
通常、これらのスイートを優先するには、スイートの順序をサーバーソフトウェアで明示的に構成する必要があります。 （役立つ展開のガイドラインについては[BETTERCRYPTO]を参照してください。ただし、その推奨事項は現在のドキュメントとは一部異なる点に注意してください。）サーバーソフトウェアの実装がこれらのスイートをデフォルトで優先するのが理想的です。
Some devices have hardware support for AES-CCM but not AES-GCM, so they are unable to follow the foregoing recommendations regarding cipher suites. There are even devices that do not support public key cryptography at all, but they are out of scope entirely.
一部のデバイスはAES-CCMをハードウェアでサポートしていますが、AES-GCMはサポートしていないため、暗号スイートに関する前述の推奨事項に従うことができません。公開鍵暗号化をまったくサポートしていないデバイスさえありますが、それらは完全に範囲外です。
Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server, unless they have prior knowledge that the server cannot respond to a TLS 1.2 client_hello message.
クライアントは、サーバーがTLS 1.2 client_helloメッセージに応答できないという事前の知識がない限り、サーバーへの最初の提案としてTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256を含める必要があります（SHOULD）。
Servers MUST prefer this cipher suite over weaker cipher suites whenever it is proposed, even if it is not the first proposal.
サーバーは、たとえ最初の提案でなくても、提案されるときはいつでも、この暗号スイートをより弱い暗号スイートよりも優先する必要があります。
Clients are of course free to offer stronger cipher suites, e.g., using AES-256; when they do, the server SHOULD prefer the stronger cipher suite unless there are compelling reasons (e.g., seriously degraded performance) to choose otherwise.
もちろん、クライアントは、AES-256などを使用して、より強力な暗号スイートを自由に提供できます。そうする場合、サーバーは、他に選択する説得力のある理由（たとえば、パフォーマンスの大幅な低下）がない限り、より強力な暗号スイートを優先する必要があります（SHOULD）。
This document does not change the mandatory-to-implement TLS cipher suite(s) prescribed by TLS. To maximize interoperability, RFC 5246 mandates implementation of the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite, which is significantly weaker than the cipher suites recommended here. (The GCM mode does not suffer from the same weakness, caused by the order of MAC-then-Encrypt in TLS [Krawczyk2001], since it uses an AEAD mode of operation.) Implementers should consider the interoperability gain against the loss in security when deploying the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. Other application protocols specify other cipher suites as mandatory to implement (MTI).
このドキュメントは、TLSで規定されている必須から実装までのTLS暗号スイートを変更しません。相互運用性を最大化するために、RFC 5246はTLS_RSA_WITH_AES_128_CBC_SHA暗号スイートの実装を義務付けています。これは、ここで推奨されている暗号スイートよりもかなり弱いです。 （GCMモードはAEADモードの操作を使用するため、TLS [Krawczyk2001]でのMAC-then-Encryptの順序が原因で発生する同じ弱点の影響を受けません。）実装者は、セキュリティの損失に対する相互運用性の向上を検討する必要があります。 TLS_RSA_WITH_AES_128_CBC_SHA暗号スイートの展開。他のアプリケーションプロトコルでは、他の暗号スイートを実装必須（MTI）として指定しています。
Note that some profiles of TLS 1.2 use different cipher suites. For example, [RFC6460] defines a profile that uses the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suites.
TLS 1.2の一部のプロファイルは異なる暗号スイートを使用していることに注意してください。たとえば、[RFC6460]は、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256およびTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384暗号スイートを使用するプロファイルを定義します。
[RFC4492] allows clients and servers to negotiate ECDH parameters (curves). Both clients and servers SHOULD include the "Supported Elliptic Curves" extension [RFC4492]. For interoperability, clients and servers SHOULD support the NIST P-256 (secp256r1) curve [RFC4492]. In addition, clients SHOULD send an ec_point_formats extension with a single element, "uncompressed".
[RFC4492]は、クライアントとサーバーがECDHパラメータ（曲線）をネゴシエートできるようにします。クライアントとサーバーの両方に、「サポートされる楕円曲線」拡張[RFC4492]を含める必要があります（SHOULD）。相互運用性のために、クライアントとサーバーはNIST P-256（secp256r1）曲線をサポートする必要があります[RFC4492]。さらに、クライアントは、単一の要素「非圧縮」でec_point_formats拡張を送信する必要があります（SHOULD）。
When using the cipher suites recommended in this document, two public keys are normally used in the TLS handshake: one for the Diffie-Hellman key agreement and one for server authentication. Where a client certificate is used, a third public key is added.
このドキュメントで推奨されている暗号スイートを使用する場合、TLSハンドシェイクでは通常2つの公開鍵が使用されます。1つはDiffie-Hellman鍵合意用で、もう1つはサーバー認証用です。クライアント証明書が使用される場合、3番目の公開鍵が追加されます。
With a key exchange based on modular exponential (MODP) Diffie-Hellman groups ("DHE" cipher suites), DH key lengths of at least 2048 bits are RECOMMENDED.
モジュラー指数（MODP）Diffie-Hellmanグループ（「DHE」暗号スイート）に基づく鍵交換では、少なくとも2048ビットのDH鍵の長さが推奨されます。
Rationale: For various reasons, in practice, DH keys are typically generated in lengths that are powers of two (e.g., 2^10 = 1024 bits, 2^11 = 2048 bits, 2^12 = 4096 bits). Because a DH key of 1228 bits would be roughly equivalent to only an 80-bit symmetric key [RFC3766], it is better to use keys longer than that for the "DHE" family of cipher suites. A DH key of 1926 bits would be roughly equivalent to a 100-bit symmetric key [RFC3766] and a DH key of 2048 bits might be sufficient for at least the next 10 years [NIST.SP.800-56A]. See Section 4.4 for additional information on the use of MODP Diffie-Hellman in TLS.
理論的根拠：実際には、DHキーは通常、2の累乗の長さで生成されます（たとえば、2 ^ 10 = 1024ビット、2 ^ 11 = 2048ビット、2 ^ 12 = 4096ビット）。 1228ビットのDH鍵は80ビットの対称鍵[RFC3766]とほぼ同等であるため、暗号スイートの「DHE」ファミリーよりも長い鍵を使用することをお勧めします。 1926ビットのDHキーは100ビット対称キー[RFC3766]とほぼ同等であり、2048ビットのDHキーは少なくとも今後10年間は十分である可能性があります[NIST.SP.800-56A]。 TLSでのMODP Diffie-Hellmanの使用に関する追加情報については、セクション4.4を参照してください。
As noted in [RFC3766], correcting for the emergence of a TWIRL machine would imply that 1024-bit DH keys yield about 65 bits of equivalent strength and that a 2048-bit DH key would yield about 92 bits of equivalent strength.
[RFC3766]で述べられているように、TWIRLマシンの出現を修正すると、1024ビットのDHキーは約65ビットの同等の強度を生成し、2048ビットのDHキーは約92ビットの同等の強度を生成します。
With regard to ECDH keys, the IANA "EC Named Curve Registry" (within the "Transport Layer Security (TLS) Parameters" registry [IANA-TLS]) contains 160-bit elliptic curves that are considered to be roughly equivalent to only an 80-bit symmetric key [ECRYPT-II]. Curves of less than 192 bits SHOULD NOT be used.
ECDHキーに関しては、IANAの「EC Named Curve Registry」（「Transport Layer Security（TLS）Parameters」レジストリ[IANA-TLS]内）には、80ビットの楕円曲線とほぼ同等と見なされる160ビットの楕円曲線が含まれています。ビット対称鍵[ECRYPT-II]。 192ビット未満の曲線は使用しないでください。
When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. In addition, the use of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for more details). Clients SHOULD indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2.
RSAを使用する場合、サーバーは、公開鍵に少なくとも2048ビットのモジュラスを持つ証明書を使用して認証する必要があります（SHOULD）。さらに、SHA-256ハッシュアルゴリズムの使用が推奨されます（詳細については、[CABベースライン]を参照してください）。クライアントは、TLS 1.2で定義された「署名アルゴリズム」拡張を使用して、SHA-256を要求することをサーバーに示す必要があります（SHOULD）。
Not all TLS implementations support both modular exponential (MODP) and elliptic curve (EC) Diffie-Hellman groups, as required by Section 4.2. Some implementations are severely limited in the length of DH values. When such implementations need to be accommodated, the following are RECOMMENDED (in priority order):
セクション4.2で要求されているように、すべてのTLS実装がモジュラー指数（MODP）および楕円曲線（EC）Diffie-Hellmanグループの両方をサポートするわけではありません。一部の実装では、DH値の長さが厳しく制限されています。このような実装に対応する必要がある場合、以下を推奨します（優先順位順）。
1. Elliptic Curve DHE with appropriately negotiated parameters (e.g., the curve to be used) and a Message Authentication Code (MAC) algorithm stronger than HMAC-SHA1 [RFC5289]
1. 楕円曲線DHEと適切にネゴシエートされたパラメーター（使用される曲線など）およびHMAC-SHA1よりも強力なメッセージ認証コード（MAC）アルゴリズム[RFC5289]
2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288], with 2048-bit Diffie-Hellman parameters
2. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 [RFC5288]、2048ビットDiffie-Hellmanパラメータ付き
3. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters Rationale: Although Elliptic Curve Cryptography is widely deployed, there are some communities where its adoption has been limited for several reasons, including its complexity compared to modular arithmetic and longstanding perceptions of IPR concerns (which, for the most part, have now been resolved [RFC6090]). Note that ECDHE cipher suites exist for both RSA and ECDSA certificates, so moving to ECDHE cipher suites does not require moving away from RSA-based certificates. On the other hand, there are two related issues hindering effective use of MODP Diffie-Hellman cipher suites in TLS:
3. 1024ビットのパラメーターを持つTLS_DHE_RSA_WITH_AES_128_GCM_SHA256理論的根拠：楕円曲線暗号は広く展開されていますが、モジュラー演算と比較した複雑さや、IPRの懸念の長年にわたる認識など、その採用が制限されているコミュニティもあります（ほとんどの部分は解決されました[RFC6090]）。 ECDHE暗号スイートはRSA証明書とECDSA証明書の両方に存在するため、ECDHE暗号スイートに移行する場合、RSAベースの証明書から移行する必要はありません。一方、TLSでのMODP Diffie-Hellman暗号スイートの効果的な使用を妨げる2つの関連する問題があります。
o There are no standardized, widely implemented protocol mechanisms to negotiate the DH groups or parameter lengths supported by client and server.
o クライアントとサーバーでサポートされているDHグループまたはパラメーターの長さをネゴシエートするための、標準化され、広く実装されているプロトコルメカニズムはありません。
o Many servers choose DH parameters of 1024 bits or fewer.
o 多くのサーバーは、1024ビット以下のDHパラメータを選択します。
o There are widely deployed client implementations that reject received DH parameters if they are longer than 1024 bits. In addition, several implementations do not perform appropriate validation of group parameters and are vulnerable to attacks referenced in Section 2.9 of [RFC7457].
o 受信したDHパラメータが1024ビットより長い場合に拒否するクライアント実装が広く展開されています。さらに、いくつかの実装はグループパラメータの適切な検証を実行せず、[RFC7457]のセクション2.9で参照されている攻撃に対して脆弱です。
Note that with DHE and ECDHE cipher suites, the TLS master key only depends on the Diffie-Hellman parameters and not on the strength of the RSA certificate; moreover, 1024 bit MODP DH parameters are generally considered insufficient at this time.
DHEおよびECDHE暗号スイートでは、TLSマスターキーはDiffie-Hellmanパラメータにのみ依存し、RSA証明書の強度には依存しないことに注意してください。さらに、現時点では、1024ビットのMODP DHパラメータは一般に不十分であると考えられています。
With MODP ephemeral DH, deployers ought to carefully evaluate interoperability vs. security considerations when configuring their TLS endpoints.
MODPエフェメラルDHを使用する場合、デプロイヤは、TLSエンドポイントを構成するときに、相互運用性とセキュリティの考慮事項を慎重に評価する必要があります。
Implementations MUST NOT use the Truncated HMAC extension, defined in Section 7 of [RFC6066].
実装では、[RFC6066]のセクション7で定義されているTruncated HMAC拡張を使用してはなりません。
Rationale: the extension does not apply to the AEAD cipher suites recommended above. However it does apply to most other TLS cipher suites. Its use has been shown to be insecure in [PatersonRS11].
理論的根拠：この拡張は、上記で推奨されているAEAD暗号スイートには適用されません。ただし、他のほとんどのTLS暗号スイートには適用されます。その使用は[PatersonRS11]で安全でないことが示されています。
The recommendations of this document primarily apply to the implementation and deployment of application protocols that are most commonly used with TLS and DTLS on the Internet today. Examples include, but are not limited to:
このドキュメントの推奨事項は主に、今日インターネット上でTLSおよびDTLSとともに最も一般的に使用されているアプリケーションプロトコルの実装と展開に適用されます。例には以下が含まれますが、これらに限定されません。
o Web software and services that wish to protect HTTP traffic with TLS.
o TLSでHTTPトラフィックを保護したいWebソフトウェアおよびサービス。
o Email software and services that wish to protect IMAP, POP3, or SMTP traffic with TLS.
o IMAP、POP3、またはSMTPトラフィックをTLSで保護したい電子メールソフトウェアおよびサービス。
o Instant-messaging software and services that wish to protect Extensible Messaging and Presence Protocol (XMPP) or Internet Relay Chat (IRC) traffic with TLS.
o TLSでExtensible Messaging and Presence Protocol（XMPP）またはInternet Relay Chat（IRC）トラフィックを保護するインスタントメッセージングソフトウェアおよびサービス。
o Realtime media software and services that wish to protect Secure Realtime Transport Protocol (SRTP) traffic with DTLS.
o セキュアメディアトランスポートプロトコル（SRTP）トラフィックをDTLSで保護したいリアルタイムメディアソフトウェアとサービス。
This document does not modify the implementation and deployment recommendations (e.g., mandatory-to-implement cipher suites) prescribed by existing application protocols that employ TLS or DTLS. If the community that uses such an application protocol wishes to modernize its usage of TLS or DTLS to be consistent with the best practices recommended here, it needs to explicitly update the existing application protocol definition (one example is [TLS-XMPP], which updates [RFC6120]).
このドキュメントは、TLSまたはDTLSを採用する既存のアプリケーションプロトコルで規定されている実装および展開の推奨事項（たとえば、必須から実装までの暗号スイート）を変更しません。このようなアプリケーションプロトコルを使用するコミュニティが、TLSまたはDTLSの使用を最新のものにして、ここで推奨されるベストプラクティスと一致させる場合は、既存のアプリケーションプロトコル定義を明示的に更新する必要があります（1つの例は[TLS-XMPP]であり、更新します[RFC6120]）。
Designers of new application protocols developed through the Internet Standards Process [RFC2026] are expected at minimum to conform to the best practices recommended here, unless they provide documentation of compelling reasons that would prevent such conformance (e.g., widespread deployment on constrained devices that lack support for the necessary algorithms).
インターネット標準プロセス[RFC2026]を通じて開発された新しいアプリケーションプロトコルの設計者は、そのような適合を妨げる説得力のある理由（例：サポートのない制約のあるデバイスでの広範囲な配備）の文書を提供しない限り、ここで推奨されるベストプラクティスに適合することが最低限期待されます。必要なアルゴリズム用）。
This document provides recommendations for an audience that wishes to secure their communication with TLS to achieve the following:
このドキュメントでは、TLSとの通信をセキュリティで保護して以下を実現することを希望する読者向けの推奨事項を提供します。
o Confidentiality: all application-layer communication is encrypted with the goal that no party should be able to decrypt it except the intended receiver.
o 機密性：すべてのアプリケーション層通信は暗号化されており、目的の受信者以外は誰も暗号化を解除できないようにする必要があります。
o Data integrity: any changes made to the communication in transit are detectable by the receiver.
o データの完全性：送信中の通信に加えられた変更は、受信者が検出できます。
o Authentication: an endpoint of the TLS communication is authenticated as the intended entity to communicate with.
o 認証：TLS通信のエンドポイントは、通信対象のエンティティとして認証されます。
With regard to authentication, TLS enables authentication of one or both endpoints in the communication. In the context of opportunistic security [RFC7435], TLS is sometimes used without authentication. As discussed in Section 5.2, considerations for opportunistic security are not in scope for this document.
認証に関して、TLSは通信の一方または両方のエンドポイントの認証を可能にします。日和見セキュリティ[RFC7435]のコンテキストでは、TLSは認証なしで使用されることがあります。セクション5.2で説明したように、日和見セキュリティに関する考慮事項は、このドキュメントの範囲外です。
If deployers deviate from the recommendations given in this document, they need to be aware that they might lose access to one of the foregoing security services.
このドキュメントに記載されている推奨事項から逸脱しているデプロイヤーは、前述のセキュリティサービスの1つにアクセスできなくなる可能性があることに注意する必要があります。
This document applies only to environments where confidentiality is required. It recommends algorithms and configuration options that enforce secrecy of the data in transit.
このドキュメントは、機密性が要求される環境にのみ適用されます。転送中のデータの機密性を強制するアルゴリズムと構成オプションを推奨します。
This document also assumes that data integrity protection is always one of the goals of a deployment. In cases where integrity is not required, it does not make sense to employ TLS in the first place. There are attacks against confidentiality-only protection that utilize the lack of integrity to also break confidentiality (see, for instance, [DegabrieleP07] in the context of IPsec).
このドキュメントでは、データ整合性保護が常に展開の目標の1つであると想定しています。整合性が要求されない場合、そもそもTLSを採用しても意味がありません。完全性の欠如を利用して機密性も破壊する、機密性のみの保護に対する攻撃があります（たとえば、IPsecのコンテキストでの[DegabrieleP07]を参照）。
This document addresses itself to application protocols that are most commonly used on the Internet with TLS and DTLS. Typically, all communication between TLS clients and TLS servers requires all three of the above security services. This is particularly true where TLS clients are user agents like Web browsers or email software.
このドキュメントでは、インターネットでTLSとDTLSを使用して最も一般的に使用されるアプリケーションプロトコルについて説明します。通常、TLSクライアントとTLSサーバー間のすべての通信には、上記の3つのセキュリティサービスすべてが必要です。これは、TLSクライアントがWebブラウザーや電子メールソフトウェアなどのユーザーエージェントである場合に特に当てはまります。
This document does not address the rarer deployment scenarios where one of the above three properties is not desired, such as the use case described in Section 5.2 below. As another scenario where confidentiality is not needed, consider a monitored network where the authorities in charge of the respective traffic domain require full access to unencrypted (plaintext) traffic, and where users collaborate and send their traffic in the clear.
このドキュメントでは、以下のセクション5.2で説明するユースケースなど、上記の3つのプロパティのいずれかが望ましくない、まれな展開シナリオについては扱いません。機密性が必要とされない別のシナリオとして、それぞれのトラフィックドメインを担当する当局が暗号化されていない（プレーンテキスト）トラフィックへのフルアクセスを必要とし、ユーザーが協力してクリアテキストでトラフィックを送信する監視対象ネットワークを検討してください。
There are several important scenarios in which the use of TLS is optional, i.e., the client decides dynamically ("opportunistically") whether to use TLS with a particular server or to connect in the clear. This practice, often called "opportunistic security", is described at length in [RFC7435] and is often motivated by a desire for backward compatibility with legacy deployments.
TLSの使用がオプションである重要なシナリオがいくつかあります。つまり、クライアントは、特定のサーバーでTLSを使用するか、クリアテキストで接続するかを動的に（「日和見的に」）決定します。この慣習は、「日和見セキュリティ」と呼ばれることが多く、[RFC7435]で詳細に説明されており、多くの場合、レガシー展開との下位互換性を求める動機になっています。
In these scenarios, some of the recommendations in this document might be too strict, since adhering to them could cause fallback to cleartext, a worse outcome than using TLS with an outdated protocol version or cipher suite.
これらのシナリオでは、このドキュメントの推奨事項の一部が厳格すぎる可能性があります。これを遵守すると、クリアテキストへのフォールバックが発生する可能性があり、古いプロトコルバージョンや暗号スイートでTLSを使用するよりも悪い結果になります。
This document specifies best practices for TLS in general. A separate document containing recommendations for the use of TLS with opportunistic security is to be completed in the future.
このドキュメントでは、TLSの一般的なベストプラクティスを示します。日和見セキュリティでのTLSの使用に関する推奨事項を含む別のドキュメントは、将来完成する予定です。
This entire document discusses the security practices directly affecting applications using the TLS protocol. This section contains broader security considerations related to technologies used in conjunction with or by TLS.
このドキュメント全体では、TLSプロトコルを使用するアプリケーションに直接影響するセキュリティプラクティスについて説明します。このセクションでは、TLSと組み合わせて、またはTLSによって使用されるテクノロジーに関連するより広範なセキュリティの考慮事項について説明します。
Application authors should take note that some TLS implementations do not validate host names. If the TLS implementation they are using does not validate host names, authors might need to write their own validation code or consider using a different TLS implementation.
アプリケーション作成者は、一部のTLS実装がホスト名を検証しないことに注意してください。使用しているTLS実装がホスト名を検証しない場合、作成者は独自の検証コードを記述するか、別のTLS実装の使用を検討する必要がある場合があります。
It is noted that the requirements regarding host name validation (and, in general, binding between the TLS layer and the protocol that runs above it) vary between different protocols. For HTTPS, these requirements are defined by Section 3 of [RFC2818].
ホスト名の検証に関する要件（および一般に、TLSレイヤーとその上で実行されるプロトコル間のバインディング）は、プロトコルによって異なります。 HTTPSの場合、これらの要件は[RFC2818]のセクション3で定義されています。
Readers are referred to [RFC6125] for further details regarding generic host name validation in the TLS context. In addition, that RFC contains a long list of example protocols, some of which implement a policy very different from HTTPS.
TLSコンテキストでの一般的なホスト名の検証に関する詳細については、[RFC6125]を参照してください。さらに、そのRFCにはプロトコル例の長いリストが含まれており、その一部はHTTPSとは非常に異なるポリシーを実装しています。
If the host name is discovered indirectly and in an insecure manner (e.g., by an insecure DNS query for an MX or SRV record), it SHOULD NOT be used as a reference identifier [RFC6125] even when it matches the presented certificate. This proviso does not apply if the host name is discovered securely (for further discussion, see [DANE-SRV] and [DANE-SMTP]).
ホスト名が間接的かつ安全でない方法で（たとえば、MXまたはSRVレコードの安全でないDNSクエリによって）検出された場合、提示された証明書と一致する場合でも、参照識別子[RFC6125]として使用しないでください。この条件は、ホスト名が安全に検出された場合は適用されません（詳細については、[DANE-SRV]および[DANE-SMTP]を参照してください）。
Host name validation typically applies only to the leaf "end entity" certificate. Naturally, in order to ensure proper authentication in the context of the PKI, application clients need to verify the entire certification path in accordance with [RFC5280] (see also [RFC6125]).
ホスト名検証は通常、リーフの「エンドエンティティ」証明書にのみ適用されます。当然、PKIのコンテキストで適切な認証を保証するために、アプリケーションクライアントは[RFC5280]（[RFC6125]も参照）に従って証明書パス全体を検証する必要があります。
Section 4.2 above recommends the use of the AES-GCM authenticated encryption algorithm. Please refer to Section 11 of [RFC5246] for general security considerations when using TLS 1.2, and to Section 6 of [RFC5288] for security considerations that apply specifically to AES-GCM when used with TLS.
上記のセクション4.2では、AES-GCM認証済み暗号化アルゴリズムの使用を推奨しています。 TLS 1.2を使用する場合の一般的なセキュリティの考慮事項については[RFC5246]のセクション11を、TLSで使用する場合にAES-GCMに特に適用されるセキュリティの考慮事項については[RFC5288]のセクション6を参照してください。
Forward secrecy (also called "perfect forward secrecy" or "PFS" and defined in [RFC4949]) is a defense against an attacker who records encrypted conversations where the session keys are only encrypted with the communicating parties' long-term keys. Should the attacker be able to obtain these long-term keys at some point later in time, the session keys and thus the entire conversation could be decrypted. In the context of TLS and DTLS, such compromise of long-term keys is not entirely implausible. It can happen, for example, due to:
転送秘密（「完全転送秘密」または「PFS」とも呼ばれ、[RFC4949]で定義されています）は、暗号化された会話を記録する攻撃者に対する防御であり、セッションキーは通信相手の長期キーでのみ暗号化されます。攻撃者がこれらの長期キーを後で取得できる場合、セッションキー、つまり会話全体が復号化される可能性があります。 TLSとDTLSのコンテキストでは、このような長期鍵の侵害は完全に信じられないことではありません。たとえば、次のことが原因で発生する可能性があります。
o A client or server being attacked by some other attack vector, and the private key retrieved.
o 他の攻撃ベクトルによって攻撃されているクライアントまたはサーバー、および取得された秘密鍵。
o A long-term key retrieved from a device that has been sold or otherwise decommissioned without prior wiping.
o 事前にワイプせずに販売された、または廃止されたデバイスから取得した長期キー。
o A long-term key used on a device as a default key [Heninger2012].
o デバイスでデフォルトのキーとして使用される長期キー[Heninger2012]。
o A key generated by a trusted third party like a CA, and later retrieved from it either by extortion or compromise [Soghoian2011].
o CAのような信頼できるサードパーティによって生成され、後で恐喝または侵害によって取得されたキー[Soghoian2011]。
o A cryptographic break-through, or the use of asymmetric keys with insufficient length [Kleinjung2010].
o 暗号のブレークスルー、または長さが不十分な非対称キーの使用[Kleinjung2010]。
o Social engineering attacks against system administrators.
o システム管理者に対するソーシャルエンジニアリング攻撃。
o Collection of private keys from inadequately protected backups.
o 保護が不十分なバックアップからの秘密鍵の収集。
Forward secrecy ensures in such cases that it is not feasible for an attacker to determine the session keys even if the attacker has obtained the long-term keys some time after the conversation. It also protects against an attacker who is in possession of the long-term keys but remains passive during the conversation.
このような場合、転送機密性により、攻撃者が会話の後にしばらくして長期キーを取得した場合でも、攻撃者がセッションキーを判別することが不可能になります。また、長期的な鍵を所持しているが会話中は受動的なままである攻撃者から保護します。
Forward secrecy is generally achieved by using the Diffie-Hellman scheme to derive session keys. The Diffie-Hellman scheme has both parties maintain private secrets and send parameters over the network as modular powers over certain cyclic groups. The properties of the so-called Discrete Logarithm Problem (DLP) allow the parties to derive the session keys without an eavesdropper being able to do so. There is currently no known attack against DLP if sufficiently large parameters are chosen. A variant of the Diffie-Hellman scheme uses Elliptic Curves instead of the originally proposed modular arithmetics.
転送秘密は、通常、Diffie-Hellmanスキームを使用してセッションキーを導出することによって実現されます。 Diffie-Hellmanスキームでは、両方の当事者がプライベートシークレットを維持し、特定の循環グループに対するモジュラーパワーとしてネットワークを介してパラメーターを送信します。いわゆる離散対数問題（DLP）の特性により、当事者は盗聴者がそれを行うことなくセッションキーを導出できます。現在、十分に大きいパラメーターが選択されている場合、DLPに対する既知の攻撃はありません。 Diffie-Hellmanスキームの変形では、最初に提案されたモジュラー演算の代わりに楕円曲線を使用します。
Unfortunately, many TLS/DTLS cipher suites were defined that do not feature forward secrecy, e.g., TLS_RSA_WITH_AES_256_CBC_SHA256. This document therefore advocates strict use of forward-secrecy-only ciphers.
残念ながら、TLS / RSA_WITH_AES_256_CBC_SHA256のように、前方秘密性を備えていない多くのTLS / DTLS暗号スイートが定義されています。したがって、このドキュメントでは、前方秘密のみの暗号の厳密な使用を推奨しています。
For performance reasons, many TLS implementations reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multiple connections. Such reuse can result in major security issues:
パフォーマンス上の理由から、多くのTLS実装は、複数の接続にわたってDiffie-HellmanおよびElliptic Curve Diffie-Hellman指数を再利用します。このような再利用は、重大なセキュリティ問題を引き起こす可能性があります。
o If exponents are reused for too long (e.g., even more than a few hours), an attacker who gains access to the host can decrypt previous connections. In other words, exponent reuse negates the effects of forward secrecy.
o 指数があまりにも長い間（たとえば、数時間以上）再利用される場合、ホストにアクセスする攻撃者は以前の接続を解読できます。言い換えれば、指数の再利用は、前方秘密の影響を打ち消します。
o TLS implementations that reuse exponents should test the DH public key they receive for group membership, in order to avoid some known attacks. These tests are not standardized in TLS at the time of writing. See [RFC6989] for recipient tests required of IKEv2 implementations that reuse DH exponents.
o 指数を再利用するTLS実装は、既知の攻撃を回避するために、グループメンバーシップについて受信するDH公開鍵をテストする必要があります。これらのテストは、執筆時点ではTLSで標準化されていません。 DH指数を再利用するIKEv2実装に必要な受信者テストについては、[RFC6989]を参照してください。
The following considerations and recommendations represent the current state of the art regarding certificate revocation, even though no complete and efficient solution exists for the problem of checking the revocation status of common public key certificates [RFC5280]:
次の考慮事項と推奨事項は、証明書の失効に関する最新の技術を表していますが、一般的な公開鍵証明書の失効ステータスをチェックする問題に対する完全で効率的な解決策はありません[RFC5280]。
o Although Certificate Revocation Lists (CRLs) are the most widely supported mechanism for distributing revocation information, they have known scaling challenges that limit their usefulness (despite workarounds such as partitioned CRLs and delta CRLs).
o 証明書失効リスト（CRL）は失効情報を配布するために最も広くサポートされているメカニズムですが、それらの有用性を制限する既知のスケーリングの課題があります（パーティション化されたCRLやデルタCRLなどの回避策にもかかわらず）。
o Proprietary mechanisms that embed revocation lists in the Web browser's configuration database cannot scale beyond a small number of the most heavily used Web servers.
o 失効リストをWebブラウザーの構成データベースに埋め込む独自のメカニズムは、最も使用頻度の高い少数のWebサーバーを超えて拡張することはできません。
o The On-Line Certification Status Protocol (OCSP) [RFC6960] presents both scaling and privacy issues. In addition, clients typically "soft-fail", meaning that they do not abort the TLS connection if the OCSP server does not respond. (However, this might be a workaround to avoid denial-of-service attacks if an OCSP responder is taken offline.)
o オンライン認証ステータスプロトコル（OCSP）[RFC6960]には、スケーリングとプライバシーの両方の問題があります。さらに、クライアントは通常「ソフトフェイル」です。つまり、OCSPサーバーが応答しない場合、クライアントはTLS接続を中止しません。 （ただし、これは、OCSPレスポンダがオフラインになった場合にサービス拒否攻撃を回避するための回避策となる場合があります。）
o The TLS Certificate Status Request extension (Section 8 of [RFC6066]), commonly called "OCSP stapling", resolves the operational issues with OCSP. However, it is still ineffective in the presence of a MITM attacker because the attacker can simply ignore the client's request for a stapled OCSP response.
o TLS証明書ステータス要求拡張（[RFC6066]のセクション8）は、一般に「OCSPステープリング」と呼ばれ、OCSPの運用上の問題を解決します。ただし、MITM攻撃者が存在する場合でも、攻撃者はステープルされたOCSP応答に対するクライアントの要求を単に無視できるため、効果がありません。
o OCSP stapling as defined in [RFC6066] does not extend to intermediate certificates used in a certificate chain. Although the Multiple Certificate Status extension [RFC6961] addresses this shortcoming, it is a recent addition without much deployment.
o [RFC6066]で定義されているOCSPステープリングは、証明書チェーンで使用される中間証明書には拡張されません。マルチ証明書ステータス拡張[RFC6961]はこの欠点に対処しますが、これはあまり展開されていない最近の追加です。
o Both CRLs and OCSP depend on relatively reliable connectivity to the Internet, which might not be available to certain kinds of nodes (such as newly provisioned devices that need to establish a secure connection in order to boot up for the first time).
o CRLとOCSPはどちらも、インターネットへの比較的信頼性の高い接続に依存しています。これは、特定の種類のノード（初めて起動するために安全な接続を確立する必要がある新しくプロビジョニングされたデバイスなど）では使用できない場合があります。
With regard to common public key certificates, servers SHOULD support the following as a best practice given the current state of the art and as a foundation for a possible future solution:
共通の公開鍵証明書に関して、サーバーは、現在の最新技術を踏まえたベストプラクティスとして、および可能な将来のソリューションの基盤として、以下をサポートする必要があります。
1. OCSP [RFC6960]
1. OCSP [RFC6960]
2. Both the status_request extension defined in [RFC6066] and the status_request_v2 extension defined in [RFC6961] (This might enable interoperability with the widest range of clients.)
2. [RFC6066]で定義されたstatus_request拡張と[RFC6961]で定義されたstatus_request_v2拡張の両方（これにより、幅広いクライアントとの相互運用が可能になる場合があります。）
3. The OCSP stapling extension defined in [RFC6961]
3. [RFC6961]で定義されているOCSPステープリング拡張
The considerations in this section do not apply to scenarios where the DANE-TLSA resource record [RFC6698] is used to signal to a client which certificate a server considers valid and good to use for TLS connections.
このセクションの考慮事項は、DANE-TLSAリソースレコード[RFC6698]を使用して、サーバーがTLS接続に有効かつ適切であると見なす証明書をクライアントに通知するシナリオには適用されません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, 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、2004年4月、<http://www.rfc-editor.org/info/rfc3766 >。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、2006年5月、<http://www.rfc-editor.org/info/rfc4492>。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、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>。
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.
[RFC5288] Salowey、J.、Choudhury、A.、D。McGrew、「AES Galois Counter Mode（GCM）Cipher Suites for TLS」、RFC 5288、2008年8月、<http://www.rfc-editor.org / info / rfc5288>。
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.
[RFC5289] Rescorla、E。、「SHA-256 / 384およびAES Galois Counter Mode（GCM）を使用したTLS楕円曲線暗号スイート」、RFC 5289、2008年8月、<http://www.rfc-editor.org/info / rfc5289>。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010, <http://www.rfc-editor.org/info/rfc5746>.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「Transport Layer Security（TLS）Renegotiation Indication Extension」、RFC 5746、2010年2月、<http：//www.rfc- editor.org/info/rfc5746>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、2011年1月、<http://www.rfc-editor.org/info/rfc6066>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, March 2011, <http://www.rfc-editor.org/info/rfc6176>.
[RFC6176]ターナー、S。およびT.ポーク、「Prohibiting Secure Sockets Layer（SSL）Version 2.0」、RFC 6176、2011年3月、<http://www.rfc-editor.org/info/rfc6176>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, February 2015, <http://www.rfc-editor.org/info/rfc7465>.
[RFC7465] Popov、A。、「Prohibiting RC4 Cipher Suites」、RFC 7465、2015年2月、<http://www.rfc-editor.org/info/rfc7465>。
[BETTERCRYPTO] bettercrypto.org, "Applied Crypto Hardening", April 2015, <https://bettercrypto.org/static/ applied-crypto-hardening.pdf>.
[BETTERCRYPTO] bettercrypto.org、「Applied Crypto Hardening」、2015年4月、<https://bettercrypto.org/static/applications-crypto-hardening.pdf>。
[CAB-Baseline] CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates Version 1.1.6", 2013, <https://www.cabforum.org/documents.html>.
[CABベースライン] CA /ブラウザフォーラム、「信頼できる証明書のバージョン1.1.6の発行と管理に関するベースライン要件」、2013、<https://www.cabforum.org/documents.html>。
[DANE-SMTP] Dukhovni, V. and W. Hardaker, "SMTP security via opportunistic DANE TLS", Work in Progress, draft-ietf-dane-smtp-with-dane-16, April 2015.
[DANE-SMTP] Dukhovni、V。およびW. Hardaker、「日和見DANE TLSによるSMTPセキュリティ」、Work in Progress、draft-ietf-dane-smtp-with-dane-16、2015年4月。
[DANE-SRV] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", Work in Progress, draft-ietf-dane-srv-14, April 2015.
[DANE-SRV] Finch、T.、Miller、M。、およびP. Saint-Andre、「DNSベースの名前付きエンティティの認証（DANE）TLSAレコードとSRVレコードの使用」、Work in Progress、draft-ietf-dane -srv-14、2015年4月。
[DEP-SSLv3] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", Work in Progress, draft-ietf-tls-sslv3-diediedie-03, April 2015.
[DEP-SSLv3] Barnes、R.、Thomson、M.、Pironti、A。、およびA. Langley、「Deprecating Secure Sockets Layer Version 3.0」、Work in Progress、draft-ietf-tls-sslv3-diediedie-03、 2015年4月。
[DegabrieleP07] Degabriele, J. and K. Paterson, "Attacking the IPsec Standards in Encryption-only Configurations", IEEE Symposium on Security and Privacy (SP '07), 2007, <http://dx.doi.org/10.1109/SP.2007.8>.
[DegabrieleP07] Degabriele、J。およびK. Paterson、「Attacking the IPsec Standards in Encryption-only Configurations」、IEEE Symposium on Security and Privacy（SP '07）、2007、<http://dx.doi.org/10.1109 /SP.2007.8>。
[ECRYPT-II] Smart, N., "ECRYPT II Yearly Report on Algorithms and Keysizes (2011-2012)", 2012, <http://www.ecrypt.eu.org/ecrypt2/>.
[ECRYPT-II] Smart、N。、「アルゴリズムとキーサイズに関するECRYPT II年次レポート（2011-2012）」、2012、<http://www.ecrypt.eu.org/ecrypt2/>。
[Heninger2012] Heninger, N., Durumeric, Z., Wustrow, E., and J. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", Usenix Security Symposium 2012, 2012.
[Heninger2012] Heninger、N.、Durumeric、Z.、Wustrow、E.、J。Halderman、「Mining Your Ps and Qs：Detection of Widespread Weak Keys in Network Devices」、Usenix Security Symposium 2012、2012。
[IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters", <http://www.iana.org/assignments/tls-parameters>.
[IANA-TLS] IANA、「Transport Layer Security（TLS）Parameters」、<http://www.iana.org/assignments/tls-parameters>。
[Kleinjung2010] Kleinjung, T., "Factorization of a 768-Bit RSA modulus", CRYPTO 10, 2010, <https://eprint.iacr.org/2010/006.pdf>.
[Kleinjung2010] Kleinjung、T。、「Factorization of 768-Bit RSA Modulus」、CRYPTO 10、2010、<https://eprint.iacr.org/2010/006.pdf>。
[Krawczyk2001] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)", CRYPTO 01, 2001, <https://www.iacr.org/archive/crypto2001/21390309.pdf>.
[Krawczyk2001] Krawczyk、H。、「通信を保護するための暗号化と認証の順序（または、SSLの安全性はどうですか？）」、CRYPTO 01、2001、<https://www.iacr.org/archive/crypto2001/21390309 .pdf>。
[Multiple-Encryption] Merkle, R. and M. Hellman, "On the security of multiple encryption", Communications of the ACM, Vol. 24, 1981, <http://dl.acm.org/citation.cfm?id=358718>.
[マルチプル暗号化]マークル、R。およびM.ヘルマン、「マルチ暗号化のセキュリティについて」、ACMの通信、Vol。 1981年24日、<http://dl.acm.org/citation.cfm?id=358718>。
[NIST.SP.800-56A] Barker, E., Chen, L., Roginsky, A., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A, 2013, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar2.pdf>.
[NIST.SP.800-56A] Barker、E.、Chen、L.、Roginsky、A。、およびM. Smid、「離散対数暗号を使用したペアワイズキー確立スキームの推奨」、NIST特別発行800-56A 、2013、<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar2.pdf>。
[POODLE] US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE Attack", Alert TA14-290A, October 2014, <https://www.us-cert.gov/ncas/alerts/TA14-290A>.
[POODLE] US-CERT、「SSL 3.0プロトコルの脆弱性とPOODLE攻撃」、アラートTA14-290A、2014年10月、<https://www.us-cert.gov/ncas/alerts/TA14-290A>。
[PatersonRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag size does matter: attacks and proofs for the TLS record protocol", 2011, <http://dx.doi.org/10.1007/978-3-642-25385-0_20>.
[PatersonRS11] Paterson、K.、Ristenpart、T。、およびT. Shrimpton、「タグのサイズは重要です：TLSレコードプロトコルの攻撃と証明」、2011、<http://dx.doi.org/10.1007/978 -3-642-25385-0_20>。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996, <http://www.rfc-editor.org/info/rfc2026>.
[RFC2026] Bradner、S。、「The Internet Standards Process-Revision 3」、BCP 9、RFC 2026、1996年10月、<http://www.rfc-editor.org/info/rfc2026>。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.
[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月、<http://www.rfc-editor.org/info/rfc2246>。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003, <http://www.rfc-editor.org/info/rfc3602>.
[RFC3602]フランケルS.、グレンR.、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPsecでのその使用」、RFC 3602、2003年9月、<http://www.rfc-editor.org / info / rfc3602>。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月、<http://www.rfc-editor.org/info/rfc4346>。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006, <http://www.rfc-editor.org/info/rfc4347>.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月、<http://www.rfc-editor.org/info/rfc4347>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「Transport Layer Security（TLS）Session Resumption without Server-Side State」、RFC 5077、2008年1月、<http：// www.rfc-editor.org/info/rfc5077>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、2008年1月、<http://www.rfc-editor.org/info/rfc5116>。
[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, 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、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月、<http://www.rfc-editor.org/info/rfc6090>。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, August 2011, <http://www.rfc-editor.org/info/rfc6101>.
[RFC6101] Freier、A.、Karlton、P。、およびP. Kocher、「Secure Sockets Layer（SSL）Protocol Version 3.0」、RFC 6101、2011年8月、<http://www.rfc-editor.org/ info / rfc6101>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月、<http://www.rfc-editor.org/info/rfc6120>。
[RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport Layer Security (TLS)", RFC 6460, January 2012, <http://www.rfc-editor.org/info/rfc6460>.
[RFC6460]ソルター、M。およびR.ハウズリー、「トランスポート層セキュリティ（TLS）のスイートBプロファイル」、RFC 6460、2012年1月、<http://www.rfc-editor.org/info/rfc6460>。
[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>。
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, November 2012, <http://www.rfc-editor.org/info/rfc6797>.
[RFC6797] Hodges、J.、Jackson、C。、およびA. Barth、「HTTP Strict Transport Security（HSTS）」、RFC 6797、2012年11月、<http://www.rfc-editor.org/info/rfc6797 >。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013, <http://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、and C. Adams、 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP"、RFC 6960、2013年6月、<http://www.rfc-editor.org/info/rfc6960>。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, June 2013, <http://www.rfc-editor.org/info/rfc6961>.
[RFC6961] Pettersen、Y。、「The Transport Layer Security（TLS）Multiple Certificate Status Request Extension」、RFC 6961、2013年6月、<http://www.rfc-editor.org/info/rfc6961>。
[RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 6989, July 2013, <http://www.rfc-editor.org/info/rfc6989>.
[RFC6989] Sheffer、Y。およびS. Fluhrer、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）の追加Diffie-Hellmanテスト」、RFC 6989、2013年7月、<http://www.rfc-editor.org/ info / rfc6989>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, February 2015, <http://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）に対する既知の攻撃の要約」、RFC 7457、2015年2月、<http：// www.rfc-editor.org/info/rfc7457>。
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, April 2015.
[RFC7507] Moeller、B。およびA. Langley、「プロトコルダウングレード攻撃を防止するためのTLSフォールバックシグナリング暗号スイート値（SCSV）」、RFC 7507、2015年4月。
[SESSION-HASH] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", Work in Progress, draft-ietf-tls-session-hash-05, April 2015.
[SESSION-HASH] Bhargavan、K.、Ed。、Delignat-Lavaud、A.、Pironti、A.、Langley、A.、and M. Ray、 "Transport Layer Security（TLS）Session Hash and Extended Master Secret Extension" 、Work in Progress、draft-ietf-tls-session-hash-05、2015年4月。
[Smith2013] Smith, B., "Proposal to Change the Default TLS Ciphersuites Offered by Browsers.", 2013, <https://briansmith.org/browser-ciphersuites-01.html>.
[Smith2013] Smith、B。、「ブラウザーが提供するデフォルトのTLS暗号スイートを変更する提案」、2013、<https://briansmith.org/browser-ciphersuites-01.html>。
[Soghoian2011] Soghoian, C. and S. Stamm, "Certified lies: Detecting and defeating government interception attacks against SSL", Proc. 15th Int. Conf. Financial Cryptography and Data Security, 2011.
[Soghoian2011] Soghoian、C。、およびS. Stamm、「認定された嘘：SSLに対する政府の傍受攻撃の検出と敗北」、Proc。 15th Int。会議Financial Cryptography and Data Security、2011年。
[TLS-XMPP] Saint-Andre, P. and a. alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, draft-ietf-uta-xmpp-07, April 2015.
[TLS-XMPP] Saint-Andre、P。、およびa。 alkemade、「Extensible Messaging and Presence Protocol（XMPP）でのトランスポート層セキュリティ（TLS）の使用」、Work in Progress、draft-ietf-uta-xmpp-07、2015年4月。
[triple-handshake] Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, "Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS", 2014, <https://secure-resumption.com/>.
[トリプルハンドシェイク] Delignat-Lavaud、A.、Bhargavan、K。、およびA. Pironti、「有害と見なされる3つのハンドシェイク：TLSを介した認証の破壊と修正」、2014、<https://secure-resumption.com/> 。
Acknowledgments
謝辞
Thanks to RJ Atkinson, Uri Blumenthal, Viktor Dukhovni, Stephen Farrell, Daniel Kahn Gillmor, Paul Hoffman, Simon Josefsson, Watson Ladd, Orit Levin, Ilari Liusvaara, Johannes Merkle, Bodo Moeller, Yoav Nir, Massimiliano Pala, Kenny Paterson, Patrick Pelletier, Tom Ritter, Joe St. Sauver, Joe Salowey, Rich Salz, Brian Smith, Sean Turner, and Aaron Zauner for their feedback and suggested improvements. Thanks also to Brian Smith, who has provided a great resource in his "Proposal to Change the Default TLS Ciphersuites Offered by Browsers" [Smith2013]. Finally, thanks to all others who commented on the TLS, UTA, and other discussion lists but who are not mentioned here by name.
RJ Atkinson、Uri Blumenthal、Viktor Dukhovni、Stephen Farrell、Daniel Kahn Gillmor、Paul Hoffman、Simon Josefsson、Watson Ladd、Orit Levin、Ilari Liusvaara、Johannes Merkle、Bodo Moeller、Yoav Nir、Massimiliano Pala、Kenny Paterson、Patrick Pelle 、フィードバックと提案された改善点について、トムリッター、ジョーセントソーバー、ジョーサロウィー、リッチザルツ、ブライアンスミス、ショーンターナー、アーロンザウナー。 「ブラウザが提供するデフォルトのTLS暗号スイートを変更する提案」[Smith2013]で優れたリソースを提供してくれたBrian Smithにも感謝します。最後に、TLS、UTA、およびその他のディスカッションリストについてコメントしたが、ここでは名前で言及されていない他のすべての人に感謝します。
Robert Sparks and Dave Waltermire provided helpful reviews on behalf of the General Area Review Team and the Security Directorate, respectively.
Robert SparksとDave Waltermireは、それぞれGeneral Area Review TeamとSecurity Directorateに代わって役立つレビューを提供しました。
During IESG review, Richard Barnes, Alissa Cooper, Spencer Dawkins, Stephen Farrell, Barry Leiba, Kathleen Moriarty, and Pete Resnick provided comments that led to further improvements.
IESGのレビュー中に、リチャードバーンズ、アリッサクーパー、スペンサードーキンス、スティーブンファレル、バリーレイバ、キャスリーンモリアーティ、およびピートレズニックは、さらなる改善につながるコメントを提供しました。
Ralph Holz gratefully acknowledges the support by Technische Universitaet Muenchen. The authors gratefully acknowledge the assistance of Leif Johansson and Orit Levin as the working group chairs and Pete Resnick as the sponsoring Area Director.
ラルフホルツは、ミュンヘン工科大学によるサポートに感謝の意を表します。執筆者は、作業グループの議長としてのLeif JohanssonとOrit Levinの支援、および後援のArea DirectorとしてのPete Resnickの支援に感謝しています。
Authors' Addresses
著者のアドレス
Yaron Sheffer Intuit 4 HaHarash St. Hod HaSharon 4524075 Israel
Yaron Sheffer Intuit 4 HaHarash St. Hod HaSharon 4524075イスラエル
EMail: yaronf.ietf@gmail.com
Ralph Holz NICTA 13 Garden St. Eveleigh 2015 NSW Australia
Ralph Holz NICTA 13 Garden St. Eveleigh 2015 NSW Australia
EMail: ralph.ietf@gmail.com
Peter Saint-Andre &yet
ピーターサンタンドレ＆まだ
EMail: peter@andyet.com
URI: https://andyet.com/