[要約] RFC 9325 は、TLSとDTLSの安全な使用を推奨する最新のガイドラインであり、TLSおよびDTLSを使用するサービスのセキュリティを確保することを目的としています。
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 9325 Intuit
BCP: 195 P. Saint-Andre
Obsoletes: 7525 Independent
Updates: 5288, 6066 T. Fossati
Category: Best Current Practice ARM Limited
ISSN: 2070-1721 November 2022
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 used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.
トランスポートレイヤーセキュリティ（TLS）およびデータグラムトランスポートレイヤーセキュリティ（DTLS）は、広範囲のアプリケーションプロトコルで交換されるデータを保護するために使用され、安全な輸送プロトコルの基礎を形成することもできます。長年にわたり、業界は、最も一般的に使用される暗号スイートやその運用モードへの攻撃など、TLSとDTLに対するいくつかの深刻な攻撃を目撃してきました。このドキュメントは、TLSとDTLSを使用する展開されたサービスのセキュリティを確保するための最新の推奨事項を提供します。これらの推奨事項は、ユースケースの大部分に適用されます。
RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.
TLS推奨事項の以前のバージョンであるRFC 7525は、業界がTLS 1.2に移行していたときに公開されました。数年後、この移行はほぼ完全であり、TLS 1.3は広く利用可能です。このドキュメントは、新しい環境と廃止RFC7525を考慮してガイダンスを更新します。さらに、このドキュメントは、最近の攻撃を考慮してRFCS 5288および6066を更新します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。BCPの詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9325.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9325で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology
3. General Recommendations
3.1. Protocol Versions
3.1.1. SSL/TLS Protocol Versions
3.1.2. DTLS Protocol Versions
3.1.3. Fallback to Lower Versions
3.2. Strict TLS
3.3. Compression
3.3.1. Certificate Compression
3.4. TLS Session Resumption
3.5. Renegotiation in TLS 1.2
3.6. Post-Handshake Authentication
3.7. Server Name Indication (SNI)
3.8. Application-Layer Protocol Negotiation (ALPN)
3.9. Multi-Server Deployment
3.10. Zero Round-Trip Time (0-RTT) Data in TLS 1.3
4. Recommendations: Cipher Suites
4.1. General Guidelines
4.2. Cipher Suites for TLS 1.2
4.2.1. Implementation Details
4.3. Cipher Suites for TLS 1.3
4.4. Limits on Key Usage
4.5. Public Key Length
4.6. Truncated HMAC
5. Applicability Statement
5.1. Security Services
5.2. Opportunistic Security
6. IANA Considerations
7. Security Considerations
7.1. Host Name Validation
7.2. AES-GCM
7.2.1. Nonce Reuse in TLS 1.2
7.3. Forward Secrecy
7.4. Diffie-Hellman Exponent Reuse
7.5. Certificate Revocation
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Differences from RFC 7525
Acknowledgments
Authors' Addresses
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide variety of application protocols, including HTTP [RFC9112] [RFC9113], IMAP [RFC9051], Post Office Protocol (POP) [STD53], SIP [RFC3261], SMTP [RFC5321], and the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. Such protocols use both the TLS or DTLS handshake protocol and the TLS or DTLS record layer. Although the TLS handshake protocol can also be used with different record layers to define secure transport protocols (the most prominent example is QUIC [RFC9000]), such transport protocols are not directly in scope for this document; nevertheless, many of the recommendations here might apply insofar as such protocols use the TLS handshake protocol.
トランスポートレイヤーセキュリティ（TLS）およびデータグラムトランスポートレイヤーセキュリティ（DTLS）は、HTTP [RFC9112] [RFC9113]、IMAP [RFC9051]、郵便局プロトコル（POP）[STD533333333333333333333333333333333333333333333333333333333の輸送レイヤーセキュリティ（DTL）を保護するために使用されます。]、SIP [RFC3261]、SMTP [RFC5321]、および拡張可能なメッセージングおよび存在プロトコル（XMPP）[RFC6120]。このようなプロトコルは、TLSまたはDTLSハンドシェイクプロトコルとTLSまたはDTLSレコードレイヤーの両方を使用します。TLSハンドシェイクプロトコルは、安全な輸送プロトコルを定義するために異なるレコードレイヤーで使用することもできますが（最も顕著な例はQUIC [RFC9000]）、このような輸送プロトコルはこのドキュメントの範囲に直接はありません。それにもかかわらず、このようなプロトコルがTLSハンドシェイクプロトコルを使用する限り、ここでの推奨事項の多くは適用される可能性があります。
Over the years leading to 2015, the industry had witnessed serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. For instance, both the AES-CBC [RFC3602] and RC4 [RFC7465] encryption algorithms, which together were once the most widely deployed ciphers, were attacked in the context of TLS. Detailed information about the attacks known prior to 2015 is provided in a companion document [RFC7457] to the previous version of the TLS recommendations [RFC7525], which will help the reader understand the rationale behind the recommendations provided here. That document has not been updated in concert with this one; instead, newer attacks are described in this document, as are mitigations for those attacks.
2015年に至る長年にわたり、業界は、最も一般的に使用される暗号スイートとその運用モードへの攻撃など、TLSとDTLに対する深刻な攻撃を目撃していました。たとえば、AES-CBC [RFC3602]とRC4 [RFC7465]暗号化アルゴリズムの両方が、かつて最も広く展開されていた暗号でしたが、TLSのコンテキストで攻撃されました。2015年以前に知られている攻撃に関する詳細な情報は、TLS推奨事項[RFC7525]の以前のバージョン[RFC7525]にコンパニオンドキュメント[RFC7457]に記載されています。そのドキュメントは、これと協力して更新されていません。代わりに、これらの攻撃の緩和と同様に、この文書に新しい攻撃が説明されています。
The TLS community reacted to the attacks described in [RFC7457] in several ways:
TLSコミュニティは、[RFC7457]に記載されている攻撃にいくつかの方法で反応しました。
* Detailed guidance was published on the use of TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347] along with earlier protocol versions. This guidance is included in the original [RFC7525] and mostly retained in this revised version; note that this guidance was mostly adopted by the industry since the publication of RFC 7525 in 2015.
* TLS 1.2 [RFC5246]およびDTLS 1.2 [RFC6347]の使用と、以前のプロトコルバージョンの使用に関する詳細なガイダンスが公開されました。このガイダンスは元の[RFC7525]に含まれており、この改訂版にほとんど保持されています。このガイダンスは、2015年にRFC 7525が発行されて以来、主に業界で採用されていたことに注意してください。
* Versions of TLS earlier than 1.2 were deprecated [RFC8996].
* 1.2未満のTLSのバージョンは非推奨でした[RFC8996]。
* Version 1.3 of TLS [RFC8446] was released, followed by version 1.3 of DTLS [RFC9147]; these versions largely mitigate or resolve the described attacks.
* TLS [RFC8446]のバージョン1.3がリリースされ、その後、DTLS [RFC9147]のバージョン1.3がリリースされました。これらのバージョンは、主に説明されている攻撃を軽減または解決します。
Those who implement and deploy TLS and TLS-based protocols need guidance on how they can be used securely. This document provides guidance for deployed services as well as for software implementations, assuming the implementer expects their code to be deployed in the environments defined in Section 5. 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および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とDTLの両方に適用されます。
This document attempts to minimize new guidance to TLS 1.2 implementations, and the overall approach is to encourage systems to move to TLS 1.3. However, this is not always practical. Newly discovered attacks, as well as ecosystem changes, necessitated some new requirements that apply to TLS 1.2 environments. Those are summarized in Appendix A.
このドキュメントは、TLS 1.2の実装への新しいガイダンスを最小限に抑えようとします。全体的なアプローチは、システムがTLS 1.3に移動することを奨励することです。ただし、これは必ずしも実用的ではありません。新たに発見された攻撃と生態系の変更には、TLS 1.2環境に適用されるいくつかの新しい要件が必要でした。これらは付録Aにまとめられています。
Naturally, future attacks are likely, and this document cannot address them. Those who implement and deploy TLS/DTLS and protocols based on TLS/DTLS are strongly advised to pay attention to future developments. In particular, although it is known that the creation of quantum computers will have a significant impact on the security of cryptographic primitives and the technologies that use them, currently post-quantum cryptography is a work in progress and it is too early to make recommendations; once the relevant specifications are standardized in the IETF or elsewhere, this document should be updated to reflect best practices at that time.
当然、将来の攻撃が可能性が高く、このドキュメントはそれらに対処できません。TLS/DTLSに基づいてTLS/DTLとプロトコルを実装および展開する人は、将来の開発に注意を払うことを強くお勧めします。特に、量子コンピューターの作成は暗号化のプリミティブとそれらを使用する技術のセキュリティに大きな影響を与えることが知られていますが、現在、Quantum後の暗号化は進行中の作業であり、推奨をするのは時期尚早です。関連する仕様がIETFまたはその他の場所で標準化されると、このドキュメントはその時点でのベストプラクティスを反映するように更新する必要があります。
As noted, the TLS 1.3 specification resolves 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. Therefore, this document replaces [RFC7525], with an explicit goal to encourage migration of most uses of TLS 1.2 to TLS 1.3.
前述のように、TLS 1.3仕様は、このドキュメントにリストされている脆弱性の多くを解決します。TLS 1.3を展開するシステムは、TLS 1.2以下よりも脆弱性が少ないはずです。したがって、このドキュメントは[RFC7525]を置き換え、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 specific 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: where feasible, administrators of services are encouraged to go beyond the minimum support available in implementations to provide the strongest security possible. For example, based on knowledge about the deployed base for an existing application protocol and a cost-benefit analysis regarding security strength vs. interoperability, a given service provider might decide to disable TLS 1.2 entirely and offer only TLS 1.3.
これらは、認識されていないTLSを除き、実装および展開シナリオの大部分でTLSを使用するための最小推奨事項です（セクション5を参照）。このドキュメントを参照するその他の仕様は、特定の状況に基づいて、プロトコルの1つ以上の側面に関連するより厳格な要件を持つことができます（たとえば、特定のアプリケーションプロトコルで使用する場合）。その場合、実装者はこれらのより厳しい要件を遵守することをお勧めします。さらに、このドキュメントは、天井ではなくフロアを提供します。実行可能な場合、サービスの管理者は、可能な限り強力なセキュリティを提供するために、実装で利用可能な最小限のサポートを超えることが奨励されています。たとえば、既存のアプリケーションプロトコルの展開ベースに関する知識と、セキュリティ強度と相互運用性に関するコストベネフィット分析に基づいて、特定のサービスプロバイダーはTLS 1.2を完全に無効にし、TLS 1.3のみを提供することを決定する場合があります。
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）ドキュメントがポイントインタイムステートメントであることが示されています。読者は、このドキュメントに適用される正誤表または更新を探すことをお勧めします。
This document updates [RFC5288] in view of the [Boeck2016] attack. See Section 7.2.1 for the details.
このドキュメントは、[boeck2016]攻撃を考慮して[RFC5288]を更新します。詳細については、セクション7.2.1を参照してください。
This document updates [RFC6066] in view of the [ALPACA] attack. See Section 3.7 for the details.
このドキュメントは、[ALPACA]攻撃を考慮して[RFC6066]を更新します。詳細については、セクション3.7を参照してください。
A number of security-related terms in this document are used in the sense defined in [RFC4949], including "attack", "authentication", "certificate", "cipher", "compromise", "confidentiality", "credential", "data integrity", "encryption", "forward secrecy", "key", "key length", "self-signed certificate", "strength", and "strong".
このドキュメントの多くのセキュリティ関連の用語は、[RFC4949]で定義されている意味で使用されます。「攻撃」、「認証」、「証明書」、「暗号」、「妥協」、「機密性」、「資格情報」など「データの整合性」、「暗号化」、「フォワード・エシュレシー」、「キー」、「キーの長さ」、「自己署名証明書」、「強さ」、および「強い」。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
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プロトコルバージョンに関する推奨事項は次のとおりです。
* Implementations MUST NOT negotiate SSL version 2.
* 実装は、SSLバージョン2を交渉してはなりません。
Rationale: Today, SSLv2 is considered insecure [RFC6176].
理論的根拠：今日、SSLV2は安全でないと見なされています[RFC6176]。
* Implementations MUST NOT negotiate SSL version 3.
* 実装は、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 Padding Oracle On Downgraded Legacy Encryption (POODLE) attack [POODLE], SSLv3 is now widely recognized as fundamentally insecure. See [RFC7568] for further details.
理論的根拠：SSLV3 [RFC6101]はSSLV2よりも改善され、いくつかの重要なセキュリティホールを差し出しましたが、強力な暗号スイートをサポートしませんでした。SSLV3はTLS拡張機能をサポートしていませんが、その一部（例：Renegotiation_Info [RFC5746]）はセキュリティが重要です。さらに、格下げされたレガシー暗号化（Poodle）攻撃[Poodle]にパディングオラクルが出現すると、SSLV3は根本的に不安定であると広く認識されています。詳細については、[RFC7568]を参照してください。
* Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].
* 実装は、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 cipher suites based on cipher block chaining (CBC) and does not warn against common padding errors. This and other recommendations in this section are in line with [RFC8996].
根拠：TLS 1.0（1999年に公開）は、多くの近代的で強力な暗号スイートをサポートしていません。さらに、TLS 1.0には、暗号ブロックチェーン（CBC）に基づく暗号スイートの記録ごとの初期化ベクトル（IV）がなく、一般的なパディングエラーに対して警告しません。このセクションのこれおよびその他の推奨事項は、[RFC8996]に沿っています。
* Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].
* 実装は、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 that were introduced with the standardization of TLS 1.2 in 2008, including the cipher suites recommended for TLS 1.2 by this document (see Section 4.2 below).
根拠：TLS 1.1（2006年に公開）は、TLS 1.0よりもセキュリティ改善ですが、2008年にTLS 1.2の標準化で導入された特定の強力な暗号スイートをサポートしていません。以下のセクション4.2）。
* Implementations MUST support TLS 1.2 [RFC5246].
* 実装は、TLS 1.2 [RFC5246]をサポートする必要があります。
Rationale: TLS 1.2 is implemented and deployed more widely than TLS 1.3 at this time, and when the recommendations in this document are followed to mitigate known attacks, the use of TLS 1.2 is as safe as the use of TLS 1.3. In most application protocols that reuse TLS and DTLS, there is no immediate need to migrate solely to TLS 1.3. Indeed, because many application clients are dependent on TLS libraries or operating systems that do not yet support TLS 1.3, proactively deprecating TLS 1.2 would introduce significant interoperability issues, thus harming security more than helping it. Nevertheless, it is expected that a future version of this BCP will deprecate the use of TLS 1.2 when it is appropriate to do so.
理論的根拠：TLS 1.2が実装され、現時点ではTLS 1.3よりも広く展開され、このドキュメントの推奨事項が既知の攻撃を緩和する場合、TLS 1.2の使用はTLS 1.3の使用と同じくらい安全です。TLSとDTLを再利用するほとんどのアプリケーションプロトコルでは、TLS 1.3のみに移行する必要はありません。実際、多くのアプリケーションクライアントは、TLS 1.3をまだサポートしていないTLSライブラリまたはオペレーティングシステムに依存しているため、TLS 1.2を積極的に非難すると、重要な相互運用性の問題が発生し、セキュリティがそれを支援する以上に害を及ぼします。それにもかかわらず、このBCPの将来のバージョンは、そうすることが適切な場合、TLS 1.2の使用を非難することが期待されています。
* Implementations SHOULD support TLS 1.3 [RFC8446] and, if implemented, MUST prefer to negotiate TLS 1.3 over earlier versions of TLS.
* 実装は、TLS 1.3 [RFC8446]をサポートする必要があり、実装されている場合、TLSのTLS 1.3をTLSの交渉を好む必要があります。
Rationale: TLS 1.3 is a major overhaul to the protocol and resolves many of the security issues with TLS 1.2. To the extent that an implementation supports TLS 1.2 (even if it defaults to TLS 1.3), it MUST follow the recommendations regarding TLS 1.2 specified in this document.
理論的根拠：TLS 1.3は、プロトコルの大きなオーバーホールであり、TLS 1.2の多くのセキュリティ問題を解決します。実装がTLS 1.2をサポートする限り（TLS 1.3にデフォルトであっても）、このドキュメントで指定されたTLS 1.2に関する推奨事項に従う必要があります。
* New transport protocols that integrate the TLS/DTLS handshake protocol and/or record layer MUST use only TLS/DTLS 1.3 (for instance, QUIC [RFC9001] took this approach). New application protocols that employ TLS/DTLS for channel or session encryption MUST integrate with both TLS/DTLS versions 1.2 and 1.3; nevertheless, in rare cases where broad interoperability is not a concern, application protocol designers MAY choose to forego TLS 1.2.
* TLS/DTLSハンドシェイクプロトコルおよび/またはレコードレイヤーを統合する新しい輸送プロトコルは、TLS/DTLS 1.3のみを使用する必要があります（たとえば、QUIC [RFC9001]がこのアプローチを採用しました）。チャネルまたはセッション暗号化にTLS/DTLSを使用する新しいアプリケーションプロトコルは、TLS/DTLSバージョン1.2および1.3の両方と統合する必要があります。それにもかかわらず、幅広い相互運用性が懸念されないまれな場合、アプリケーションプロトコル設計者はTLS 1.2をめぐることを選択する場合があります。
Rationale: Secure deployment of TLS 1.3 is significantly easier and less error prone than secure deployment of TLS 1.2. When designing a new secure transport protocol such as QUIC, there is no reason to support TLS 1.2. By contrast, new application protocols that reuse TLS need to support both TLS 1.3 and TLS 1.2 in order to take advantage of underlying library or operating system support for both versions.
理論的根拠：TLS 1.3の安全な展開は、TLS 1.2の安全な展開よりも大幅に容易であり、エラーが発生しやすいです。QUICなどの新しい安全な輸送プロトコルを設計するとき、TLS 1.2をサポートする理由はありません。対照的に、TLSを再利用する新しいアプリケーションプロトコルは、両方のバージョンの基礎となるライブラリまたはオペレーティングシステムサポートを活用するために、TLS 1.3とTLS 1.2の両方をサポートする必要があります。
This BCP applies to TLS 1.3, TLS 1.2, and 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.3、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が公開されたときに導入されました。以下は、DTLに関する推奨事項です。
* Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].
* 実装は、DTLSバージョン1.0 [RFC4347]を交渉してはなりません。
Version 1.0 of DTLS correlates to version 1.1 of TLS (see above).
DTLSのバージョン1.0は、TLSのバージョン1.1と相関しています（上記参照）。
* Implementations MUST support DTLS 1.2 [RFC6347].
* 実装は、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はありません。）
* Implementations SHOULD support DTLS 1.3 [RFC9147] and, if implemented, MUST prefer to negotiate DTLS version 1.3 over earlier versions of DTLS.
* 実装はDTLS 1.3 [RFC9147]をサポートする必要があり、実装されている場合は、以前のバージョンのDTLSでDTLSバージョン1.3をネゴシエートすることを好む必要があります。
Version 1.3 of DTLS correlates to version 1.3 of TLS (see above).
DTLSのバージョン1.3は、TLSのバージョン1.3と相関しています（上記参照）。
TLS/DTLS 1.2 clients MUST NOT fall back to earlier TLS versions, since those versions have been deprecated [RFC8996]. As a result, the downgrade-protection Signaling Cipher Suite Value (SCSV) mechanism [RFC7507] is no longer needed for clients. In addition, TLS 1.3 implements a new version-negotiation mechanism.
TLS/DTLS 1.2クライアントは、これらのバージョンが非推奨であるため、以前のTLSバージョンに戻ってはなりません[RFC8996]。その結果、クライアントにはダウングレード保護シグナリング暗号スイート値（SCSV）メカニズム[RFC7507]は必要ありません。さらに、TLS 1.3は新しいバージョン交渉メカニズムを実装します。
The following recommendations are provided to help prevent "SSL Stripping" and STARTTLS command injection (attacks that are summarized in [RFC7457]):
「SSLストリッピング」およびStartTLSコマンドインジェクション（[RFC7457]に要約されている攻撃）を防ぐために、以下の推奨事項が提供されています。
* Many existing application protocols were designed before the use of TLS became common. These protocols typically support TLS in one of two ways: either via a separate port for TLS-only communication (e.g., port 443 for HTTPS) or via a method for dynamically upgrading a channel from unencrypted to TLS protected (e.g., STARTTLS, which is used in protocols such as IMAP and XMPP). Regardless of the mechanism for protecting the communication channel (TLS-only port or dynamic upgrade), what matters is the end state of the channel. When a protocol defines both a dynamic upgrade method and a separate TLS-only method, then the separate TLS-only method MUST be supported by implementations and MUST be configured by administrators to be used in preference to the dynamic upgrade method. When a protocol supports only a dynamic upgrade method, implementations MUST provide a way for administrators to set a strict local policy that forbids use of plaintext in the absence of a negotiated TLS channel, and administrators MUST use this policy.
* TLSの使用が一般的になる前に、多くの既存のアプリケーションプロトコルが設計されました。これらのプロトコルは通常、TLSを2つの方法のいずれかのいずれかでサポートしています。TLSのみの通信のための別のポート（HTTPSのポート443など）を介して、または暗号化されていないTLSから保護されたTLSにチャネルを動的にアップグレードする方法（例えば、startTLS、 IMAPやXMPPなどのプロトコルで使用されます）。通信チャネル（TLSのみのポートまたはダイナミックアップグレード）を保護するメカニズムに関係なく、重要なのはチャネルの終了状態です。プロトコルが動的アップグレードメソッドと個別のTLSのみの方法の両方を定義する場合、個別のTLSのみのメソッドを実装によってサポートする必要があり、動的アップグレードメソッドを優先して使用するように管理者が構成する必要があります。プロトコルが動的アップグレードメソッドのみをサポートする場合、実装は、管理者がネゴシエートされたTLSチャネルがない場合にプレーンテキストの使用を禁止する厳格なローカルポリシーを設定する方法を提供する必要があり、管理者はこのポリシーを使用する必要があります。
* HTTP client and server implementations intended for use in the World Wide Web (see Section 5) MUST support the HTTP Strict Transport Security (HSTS) header field [RFC6797] so that web servers can advertise that they are willing to accept TLS-only clients. 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]). Similar technologies exist for non-HTTP application protocols, such as Mail Transfer Agent Strict Transport Security (MTA-STS) for mail transfer agents [RFC8461] and methods based on DNS-Based Authentication of Named Entities (DANE) [RFC6698] for SMTP [RFC7672] and XMPP [RFC7712].
* World Wide Webで使用することを目的としたHTTPクライアントおよびサーバーの実装（セクション5を参照）は、HTTP Strict Transport Security（HSTS）Headerフィールド[RFC6797]をサポートする必要があります。これにより、WebサーバーはTLSのみのクライアントを受け入れる意思があることを宣伝できます。WebサーバーはHSTSを使用して、HSTを使用すると全体的なセキュリティを弱めるような方法で展開されない限り、TLSのみのクライアントを受け入れることを望んでいることを示す必要があります（たとえば、自己署名証明書でHSTSを使用することは問題があります。、[RFC6797]のセクション11.3で説明されているように。メール転送エージェントのStrict Transport Security（MTA-STS）などの非HTTPアプリケーションプロトコル（RFC8461]およびSMTPの名前付きエンティティ（DANE）[RFC6698]のDNSベースの認証に基づく方法など、同様の技術が存在します[RFC8461] [RFC6698]RFC7672]およびXMPP [RFC7712]。
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]) when using TLS 1.2, implementations and deployments SHOULD NOT support TLS-level compression (Section 6.2.2 of [RFC5246]); the only exception is when the application protocol in question has been proven not to be open to such attacks. However, even in this case, extreme caution is warranted because of the potential for future attacks related to TLS compression. More specifically, the HTTP protocol is known to be vulnerable to compression-related attacks. (This recommendation applies to TLS 1.2 only, because compression has been removed from TLS 1.3.)
TLS 1.2を使用する場合、圧縮関連の攻撃を防ぐために（[RFC7457]のセクション2.6に要約）、実装と展開はTLSレベルの圧縮をサポートしてはなりません（[RFC5246]のセクション6.2.2]）。唯一の例外は、問題のアプリケーションプロトコルがそのような攻撃に対して開かれていないことが証明された場合です。ただし、この場合でも、TLS圧縮に関連する将来の攻撃の可能性があるため、極端な注意が必要です。より具体的には、HTTPプロトコルは、圧縮関連の攻撃に対して脆弱であることが知られています。（この推奨事項は、TLS 1.2からTLS 1.3から削除されたため、TLS 1.2にのみ適用されます。）
Rationale: TLS compression has been subject to security attacks such as the Compression Ratio Info-leak Made Easy (CRIME) attack.
理論的根拠：TLS圧縮は、簡単な（犯罪）攻撃を行う圧縮情報リークなどのセキュリティ攻撃の対象となります。
Implementers should note that compression at higher protocol levels can allow an active attacker to extract cleartext information from the connection. The Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (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.
実装者は、より高いプロトコルレベルでの圧縮により、アクティブな攻撃者が接続からクリアテキスト情報を抽出できることに注意する必要があります。ハイパーテキスト（ブリーチ）攻撃の適応圧縮によるブラウザ偵察と除去は、そのようなケースの1つです。これらの問題は、TLS以外でのみ軽減でき、したがってこのドキュメントの範囲外です。詳細については、[RFC7457]のセクション2.6を参照してください。
Certificate chains often take up most of the bytes transmitted during the handshake. In order to manage their size, some or all of the following methods can be employed (see also Section 4 of [RFC9191] for further suggestions):
多くの場合、証明書チェーンは、握手中に送信されるバイトのほとんどを占有します。サイズを管理するために、次の方法の一部またはすべてを使用できます（さらなる提案については[RFC9191]のセクション4も参照）。
* Limit the number of names or extensions.
* 名前または拡張機能の数を制限します。
* Use keys with small public key representations, like the Elliptic Curve Digital Signature Algorithm (ECDSA).
* Elliptic Curve Digital Signature Algorithm（ECDSA）など、小さな公開キー表現を持つキーを使用します。
* Use certificate compression.
* 証明書圧縮を使用します。
To achieve the latter, TLS 1.3 defines the compress_certificate extension in [RFC8879]. See also Section 5 of [RFC8879] for security and privacy considerations associated with its use. For the avoidance of doubt, CRIME-style attacks on TLS compression do not apply to certificate compression.
後者を達成するために、TLS 1.3は[RFC8879]のCompress_Certificate拡張機能を定義します。その使用に関連するセキュリティとプライバシーの考慮事項については、[RFC8879]のセクション5も参照してください。疑いを回避するために、TLS圧縮に対する犯罪スタイルの攻撃は証明書圧縮には適用されません。
Due to the strong likelihood of middlebox interference, compression in the style of [RFC8879] has not been made available in TLS 1.2. In theory, the cached_info extension defined in [RFC7924] could be used, but it is not supported widely enough to be considered a practical alternative.
ミドルボックス干渉の可能性が強いため、[RFC8879]のスタイルの圧縮はTLS 1.2で利用可能にされていません。理論的には、[RFC7924]で定義されているCACHED_INFO拡張機能を使用できますが、実用的な選択肢と見なされるほど広くサポートされていません。
Session resumption drastically reduces the number of full TLS handshakes and thus is an essential performance feature for most deployments.
セッション再開は、完全なTLSハンドシェイクの数を大幅に削減するため、ほとんどの展開に不可欠なパフォーマンス機能です。
Stateless session resumption with session tickets is a popular strategy. For TLS 1.2, it is specified in [RFC5077]. For TLS 1.3, a more secure mechanism based on the use of a pre-shared key (PSK) is described in Section 4.6.1 of [RFC8446]. See [Springall16] for a quantitative study of the risks induced by TLS cryptographic "shortcuts", including session resumption.
セッションチケットとのステートレスセッション再開は、一般的な戦略です。TLS 1.2の場合、[RFC5077]で指定されています。TLS 1.3の場合、事前共有キー（PSK）の使用に基づくより安全なメカニズムは、[RFC8446]のセクション4.6.1で説明されています。[Springall16]は、セッション再開を含むTLS暗号化の「ショートカット」によって引き起こされるリスクの定量的研究を参照してください。
When it is used, the resumption information MUST be authenticated and encrypted to prevent modification or eavesdropping by an attacker. Further recommendations apply to session tickets:
使用する場合、再開情報を認証および暗号化して、攻撃者による修正や盗聴を防ぐ必要があります。セッションチケットには、さらなる推奨事項が適用されます。
* A strong cipher MUST be used when encrypting the ticket (at least as strong as the main TLS cipher suite).
* チケットを暗号化するときは、強力な暗号を使用する必要があります（少なくともメインTLS暗号スイートと同じくらい強力です）。
* Ticket-encryption keys MUST be changed regularly, e.g., once every week, so as not to negate the benefits of forward secrecy (see Section 7.3 for details on forward secrecy). Old ticket-encryption keys MUST be destroyed at the end of the validity period.
* チケットの暗号化キーは、前方の秘密の利点を無効にしないように、たとえば毎週1回、定期的に変更する必要があります（Forward Secrecyの詳細については、セクション7.3を参照）。妥当性期間の終わりに、古いチケット暗号化キーを破壊する必要があります。
* For similar reasons, session ticket validity MUST be limited to a reasonable duration (e.g., half as long as ticket-encryption key validity).
* 同様の理由で、セッションチケットの有効性は、合理的な期間に制限する必要があります（たとえば、チケット暗号化のキーの妥当性と同じくらい半分の長さ）。
* TLS 1.2 does not roll the session key forward within a single session. Thus, to prevent an attack where the server's ticket-encryption key is stolen and used to decrypt the entire content of a session (negating the concept of forward secrecy), a TLS 1.2 server SHOULD NOT resume sessions that are too old, e.g., sessions that have been open longer than two ticket-encryption key rotation periods.
* TLS 1.2は、1回のセッション内でセッションキーを前方に転がしません。したがって、サーバーのチケット暗号化キーが盗まれ、セッションのコンテンツ全体を復号化するために使用される攻撃を防ぐために（Forward Secrecyの概念を無効にする）、TLS 1.2サーバーは古すぎるセッション、たとえばセッションを再開すべきではありません。これは、2つ以上のチケット暗号化キーローテーション期間を超えて開いています。
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エンドポイント（クライアントまたはサーバー）への瞬間的なアクセスを獲得する攻撃者と、過去または将来のコミュニケーションを読むことを妨げる攻撃者を妨げることを推奨しています。このセキュリティプロパティを否定しないように、チケットは管理する必要があります。
TLS 1.3 provides the powerful option of forward secrecy even within a long-lived connection that is periodically resumed. Section 2.2 of [RFC8446] recommends that clients SHOULD send a "key_share" when initiating session resumption. In order to gain forward secrecy, this document recommends that server implementations SHOULD select the "psk_dhe_ke" PSK key exchange mode and respond with a "key_share" to complete an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) exchange on each session resumption. As a more performant alternative, server implementations MAY refrain from responding with a "key_share" until a certain amount of time (e.g., measured in hours) has passed since the last ECDHE exchange; this implies that the "key_share" operation would not occur for the presumed majority of session resumption requests (which would occur within a few hours) while still ensuring forward secrecy for longer-lived sessions.
TLS 1.3は、定期的に再開される長寿命の接続内であっても、フォワード秘密の強力なオプションを提供します。[RFC8446]のセクション2.2は、セッション再開を開始するときにクライアントが「key_share」を送信することを推奨しています。先進的な秘密を獲得するために、このドキュメントは、サーバーの実装が「PSK_DHE_KE」PSKキー交換モードを選択し、「key_share」で応答して、各セッションの再開で一時的な楕円曲線diffie-hellman（ecdhe）交換を完了することを推奨しています。よりパフォーマンスのある代替品として、サーバーの実装は、一定の時間（たとえば、時間で測定）が最後のECDHE交換以来通過するまで「key_share」で応答することを控えることができます。これは、「key_share」操作が、長期的なセッションの秘密を確保しながら、セッション再開リクエストの大部分（数時間以内に発生する）で発生しないことを意味します。
TLS session resumption introduces potential privacy issues where the server is able to track the client, in some cases indefinitely. See [Sy2018] for more details.
TLSセッション再開は、サーバーがクライアントを追跡できる場合によっては、場合によっては無期限にクライアントを追跡できる潜在的なプライバシーの問題を導入します。詳細については、[SY2018]を参照してください。
The recommendations in this section apply to TLS 1.2 only, because renegotiation has been removed from TLS 1.3.
このセクションの推奨事項は、再交渉がTLS 1.3から削除されたため、TLS 1.2にのみ適用されます。
Renegotiation in TLS 1.2 is a handshake that establishes new cryptographic parameters for an existing session. The mechanism existed in TLS 1.2 and in earlier protocol versions and was improved following several major attacks including a plaintext injection attack, CVE-2009-3555 [CVE].
TLS 1.2の再交渉は、既存のセッションの新しい暗号化パラメーターを確立する握手です。このメカニズムは、TLS 1.2および以前のプロトコルバージョンに存在し、Plantext Injection Attack、CVE-2009-3555 [CVE]を含むいくつかの主要な攻撃に続いて改善されました。
TLS 1.2 clients and servers MUST implement the renegotiation_info extension, as defined in [RFC5746].
TLS 1.2クライアントとサーバーは、[RFC5746]で定義されているように、Renegotiation_Info拡張機能を実装する必要があります。
TLS 1.2 clients MUST send renegotiation_info in the Client Hello. If the server does not acknowledge the extension, the client MUST generate a fatal handshake_failure alert prior to terminating the connection.
TLS 1.2クライアントは、Client HelloでRenegotiation_Infoを送信する必要があります。サーバーが拡張機能を確認しない場合、クライアントは接続を終了する前に致命的なhandshake_failureアラートを生成する必要があります。
Rationale: It is not safe for a client to connect to a TLS 1.2 server that does not support renegotiation_info regardless of whether either endpoint actually implements renegotiation. See also Section 4.1 of [RFC5746].
根拠：いずれかのエンドポイントが実際に再交渉を実装するかどうかに関係なく、クライアントがRenegotiation_infoをサポートしないTLS 1.2サーバーに接続することは安全ではありません。[RFC5746]のセクション4.1も参照してください。
A related attack resulting from TLS session parameters not being properly authenticated is a Triple Handshake [Triple-Handshake]. To address this attack, TLS 1.2 implementations MUST support the extended_master_secret extension defined in [RFC7627].
TLSセッションパラメーターが適切に認証されていないことに起因する関連攻撃は、トリプルハンドシェイク[トリプルハンドシェイク]です。この攻撃に対処するために、TLS 1.2実装は[RFC7627]で定義されている拡張_Master_Secret拡張機能をサポートする必要があります。
Renegotiation in TLS 1.2 was (partially) replaced in TLS 1.3 by separate post-handshake authentication and key update mechanisms. In the context of protocols that multiplex requests over a single connection (such as HTTP/2 [RFC9113]), post-handshake authentication has the same problems as TLS 1.2 renegotiation. Multiplexed protocols SHOULD follow the advice provided for HTTP/2 in Section 9.2.3 of [RFC9113].
TLS 1.2の再交渉は、TLS 1.3では（部分的に）個別のポストシェイク認証と主要な更新メカニズムによって置き換えられました。単一の接続（HTTP/2 [RFC9113]など）でマルチプレックスが要求するプロトコルのコンテキストでは、ポストハンドシェイク認証には、TLS 1.2再交渉と同じ問題があります。多重化されたプロトコルは、[RFC9113]のセクション9.2.3でHTTP/2に提供されるアドバイスに従う必要があります。
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. At the time of writing, a technology for encrypting the SNI (called Encrypted Client Hello) is being worked on in the TLS Working Group [TLS-ECH]. Once that method has been standardized and widely implemented, it will likely be appropriate to recommend its usage in a future version of this BCP.
TLS実装は、HTTPを含む高レベルのプロトコルについて、[RFC6066]のセクション3で定義されているサーバー名表示（SNI）拡張をサポートする必要があります。ただし、特定の状況でのSNIの実際の使用は、現地のポリシーの問題です。執筆時点では、SNIを暗号化するためのテクノロジー（暗号化されたクライアントHelloと呼ばれる）がTLSワーキンググループ[TLS-ECH]で取り組んでいます。その方法が標準化され、広く実装されると、このBCPの将来のバージョンでの使用を推奨することが適切である可能性があります。
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. However, SNI also leaks the target domain for a given connection; this information leak will be closed by use of TLS Encrypted Client Hello once that method has been standardized.
理論的根拠：SNIは、単一のアドレスで複数のTLS保護された仮想サーバーの展開をサポートするため、それぞれが独自の証明書を作成できるようにすることにより、これらの仮想サーバーの細かいセキュリティを可能にします。ただし、SNIは、特定の接続のターゲットドメインも漏れます。この情報が標準化されたら、この情報リークは、TLS暗号化されたクライアントHelloを使用することにより閉鎖されます。
In order to prevent the attacks described in [ALPACA], a server that does not recognize the presented server name SHOULD NOT continue the handshake and instead SHOULD fail with a fatal-level unrecognized_name(112) alert. Note that this recommendation updates Section 3 of [RFC6066], which stated:
[Alpaca]に記載されている攻撃を防ぐために、提示されたサーバー名を認識しないサーバーは、握手を継続するべきではなく、代わりに致命的なレベルのUnecognized_name（112）アラートで失敗するはずです。この推奨事項は、[RFC6066]のセクション3を更新することに注意してください。
If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake.
サーバーがClientHello拡張機能を理解しているが、サーバー名を認識していない場合、サーバーは2つのアクションのいずれかを実行する必要があります。
Clients SHOULD abort the handshake if the server acknowledges the SNI extension but presents a certificate with a different hostname than the one sent by the client.
サーバーがSNI拡張機能を認めているが、クライアントが送信したホスト名とは異なるホスト名で証明書を提示する場合、クライアントはハンドシェイクを中止する必要があります。
TLS implementations (both client- and server-side) MUST support the Application-Layer Protocol Negotiation (ALPN) extension [RFC7301].
TLS実装（クライアントおよびサーバー側の両方）は、アプリケーション層プロトコルネゴシエーション（ALPN）拡張[RFC7301]をサポートする必要があります。
In order to prevent "cross-protocol" attacks resulting from failure to ensure that a message intended for use in one protocol cannot be mistaken for a message for use in another protocol, servers are advised to strictly enforce the behavior prescribed in Section 3.2 of [RFC7301]:
あるプロトコルでの使用を目的としたメッセージが別のプロトコルでの使用のメッセージと間違えられないことを保証しないことに起因する「クロスプロトコル」攻撃を防ぐために、サーバーは[]のセクション3.2で規定されている動作を厳密に実施することをお勧めします。RFC7301]：
In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal 'no_application_protocol' alert.
サーバーがクライアントが宣伝するプロトコルをサポートしていない場合、サーバーは致命的な 'no_application_protocol'アラートで応答するものとします。
Clients SHOULD abort the handshake if the server acknowledges the ALPN extension but does not select a protocol from the client list. Failure to do so can result in attacks such those described in [ALPACA].
サーバーがALPN拡張機能を認めているが、クライアントリストからプロトコルを選択しない場合、クライアントはハンドシェイクを中止する必要があります。そうしないと、[Alpaca]に記載されている攻撃が発生する可能性があります。
Protocol developers are strongly encouraged to register an ALPN identifier for their protocols. This applies both to new protocols and to well-established protocols; however, because the latter might have a large deployed base, strict enforcement of ALPN usage may not be feasible when an ALPN identifier is registered for a well-established protocol.
プロトコル開発者は、プロトコルのALPN識別子を登録することを強くお勧めします。これは、新しいプロトコルと確立されたプロトコルの両方に適用されます。ただし、後者には大きな展開ベースがある可能性があるため、ALPN識別子が確立されたプロトコルに登録されている場合、ALPN使用の厳密な施行は実行不可能な場合があります。
Deployments that involve multiple servers or services can increase the size of the attack surface for TLS. Two scenarios are of interest:
複数のサーバーまたはサービスを含む展開は、TLSの攻撃面のサイズを増やすことができます。2つのシナリオが興味深いものです。
1. Deployments in which multiple services handle the same domain name via different protocols (e.g., HTTP and IMAP). In this case, an attacker might be able to direct a connecting endpoint to the service offering a different protocol and mount a cross-protocol attack. In a cross-protocol attack, the client and server believe they are using different protocols, which the attacker might exploit if messages sent in one protocol are interpreted as messages in the other protocol with undesirable effects (see [ALPACA] for more detailed information about this class of attacks). To mitigate this threat, service providers SHOULD deploy ALPN (see Section 3.8). In addition, to the extent possible, they SHOULD ensure that multiple services handling the same domain name provide equivalent levels of security that are consistent with the recommendations in this document; such measures SHOULD include the handling of configurations across multiple TLS servers and protections against compromise of credentials held by those servers.
1. 複数のサービスが異なるプロトコル（HTTPやIMAPなど）を介して同じドメイン名を処理する展開。この場合、攻撃者は、別のプロトコルを提供するサービスに接続エンドポイントを指示し、クロスプロトコル攻撃を実施できる可能性があります。クロスプロトコル攻撃では、クライアントとサーバーは、異なるプロトコルを使用していると考えています。1つのプロトコルで送信されたメッセージが、望ましくない効果を持つ他のプロトコルのメッセージとして解釈される場合、攻撃者は悪用する可能性があります（[Alpaca]を参照してください。このクラスの攻撃）。この脅威を軽減するために、サービスプロバイダーはALPNを展開する必要があります（セクション3.8を参照）。さらに、可能な限り、同じドメイン名を処理する複数のサービスが、このドキュメントの推奨事項と一致する同等のレベルのセキュリティを提供するようにする必要があります。このような手段には、複数のTLSサーバーにわたる構成の処理と、それらのサーバーが保持している資格情報の妥協に対する保護を含める必要があります。
2. Deployments in which multiple servers providing the same service have different TLS configurations. In this case, an attacker might be able to direct a connecting endpoint to a server with a TLS configuration that is more easily exploitable (see [DROWN] for more detailed information about this class of attacks). To mitigate this threat, service providers SHOULD ensure that all servers providing the same service provide equivalent levels of security that are consistent with the recommendations in this document.
2. 同じサービスを提供する複数のサーバーが異なるTLS構成の展開。この場合、攻撃者は、このクラスの攻撃の詳細については、より簡単に搾取可能なTLS構成を使用して、接続エンドポイントをサーバーに向けることができる場合があります。この脅威を軽減するために、サービスプロバイダーは、同じサービスを提供するすべてのサーバーが、このドキュメントの推奨事項と一致する同等のレベルのセキュリティを提供することを保証する必要があります。
The 0-RTT early data feature is new in TLS 1.3. It provides reduced latency when TLS connections are resumed, at the potential cost of certain security properties. As a result, it requires special attention from implementers on both the server and the client side. Typically, this extends to the TLS library as well as protocol layers above it.
0-RTT初期データ機能は、TLS 1.3で新しくなっています。特定のセキュリティプロパティの潜在的なコストで、TLS接続が再開されたときにレイテンシが低下します。その結果、サーバー側とクライアント側の両方の実装者からの特別な注意が必要です。通常、これはTLSライブラリとその上のプロトコル層に拡張されます。
For HTTP over TLS, refer to [RFC8470] for guidance.
TLSを超えるHTTPについては、ガイダンスについては[RFC8470]を参照してください。
For QUIC on TLS, refer to Section 9.2 of [RFC9001].
TLSのQUICについては、[RFC9001]のセクション9.2を参照してください。
For other protocols, generic guidance is given in Section 8 and Appendix E.5 of [RFC8446]. To paraphrase Appendix E.5, applications MUST avoid this feature unless an explicit specification exists for the application protocol in question to clarify when 0-RTT is appropriate and secure. This can take the form of an IETF RFC, a non-IETF standard, or documentation associated with a non-standard protocol.
他のプロトコルについては、[RFC8446]のセクション8および付録E.5に汎用ガイダンスが示されています。付録E.5を言い換えるには、問題のアプリケーションプロトコルの明示的な仕様が存在しない限り、アプリケーションは、0-RTTが適切かつ安全であるかを明確にする必要があります。これにより、IETF RFCの形、非標準プロトコルに関連付けられたドキュメントの形式を取ることができます。
TLS 1.2 provided considerable flexibility in the selection of cipher suites. Unfortunately, the security of some of these cipher suites has degraded over time to the point where some are known to be insecure (this is one reason why TLS 1.3 restricted such flexibility). Incorrectly configuring a server leads to no or reduced security. This section includes recommendations on the selection and negotiation of cipher suites.
TLS 1.2は、暗号スイートの選択にかなりの柔軟性を提供しました。残念ながら、これらの暗号スイートのいくつかのセキュリティは、一部の人々が不安定であることが知られているところまで時間の経過とともに劣化してきました（これがTLS 1.3がこのような柔軟性を制限した理由の1つです）。サーバーを誤って構成すると、セキュリティがNOまたは減少します。このセクションには、暗号スイートの選択と交渉に関する推奨事項が含まれています。
Cryptographic algorithms weaken over time as cryptanalysis improves: algorithms that were once considered strong become weak. Consequently, cipher suites using weak algorithms need to be phased out 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 well over 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で推奨されている多くの暗号スイートは現在、弱いか、少なくとも望ましいほど強くないと考えられています。したがって、このセクションは、暗号スイートの選択に関する推奨事項を近代化します。
* Implementations MUST NOT negotiate the cipher suites with NULL encryption.
* 実装は、null暗号化で暗号スイートを交渉してはなりません。
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暗号スイートの実装を妨げるものではありません。
* Implementations MUST NOT negotiate RC4 cipher suites.
* 実装は、RC4暗号スイートと交渉してはなりません。
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.
根拠：RC4ストリーム暗号には、[RFC7465]に記載されているように、さまざまな暗号化の弱点があります。DTLSは、既にRC4の使用を特に禁止していることに注意してください。
* Implementations MUST NOT negotiate cipher suites offering less than 112 bits of security, including so-called "export-level" encryption (which provides 40 or 56 bits of security).
* 実装は、いわゆる「エクスポートレベル」暗号化（40または56ビットのセキュリティを提供する）を含む、112ビット未満のセキュリティを提供する暗号スイートと交渉してはなりません。
Rationale: Based on [RFC3766], at least 112 bits of security is needed. 40-bit and 56-bit security (found in so-called "export ciphers") are considered insecure today.
根拠：[RFC3766]に基づいて、少なくとも112ビットのセキュリティが必要です。40ビットと56ビットのセキュリティ（いわゆる「エクスポート暗号」にある）は、今日では不安定であると考えられています。
* Implementations SHOULD NOT negotiate cipher suites that use algorithms offering less than 128 bits of security.
* 実装は、128ビット未満のセキュリティを提供するアルゴリズムを使用する暗号スイートと交渉すべきではありません。
Rationale: Cipher suites that offer 112 or more bits but less than 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 Triple DES (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ビットの暗号を保護することが期待されています。いわゆる「中間のミドル」攻撃[複数の暗号化]のために、いくつかのレガシー暗号スイート（例：168ビットトリプルDE（3DES））は、それらよりも小さい有効なキー長を持っていることに注意してください。公称キー長（3DESの場合は112ビット）。このような暗号スイートは、有効なキーの長さに従って評価する必要があります。
* Implementations SHOULD NOT negotiate cipher suites based on RSA key transport, a.k.a. "static RSA".
* 実装は、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_*」から始まる値を割り当てたこれらの暗号スイートには、特にForward Secrecyをサポートしていないという事実がいくつかあります。
* Implementations SHOULD NOT negotiate cipher suites based on non-ephemeral (static) finite-field Diffie-Hellman (DH) key agreement. Similarly, implementations SHOULD NOT negotiate non-ephemeral Elliptic Curve DH key agreement.
* 実装は、非femeral（静的）有限フィールドDiffie-Hellman（DH）キー契約に基づいて暗号スイートと交渉すべきではありません。同様に、実装は、非著しい楕円曲線DHキー契約と交渉すべきではありません。
Rationale: The former cipher suites, which have assigned values prefixed by "TLS_DH_*", have several drawbacks, especially the fact that they do not support forward secrecy. The latter ("TLS_ECDH_*") also lack forward secrecy and are subject to invalid curve attacks [Jager2015].
理論的根拠：「TLS_DH_*」が付けた値を割り当てた以前の暗号スイートには、いくつかの欠点、特にフォワードの秘密をサポートしていないという事実があります。後者（ "TLS_ECDH_*"）も前向きな秘密を欠いており、無効な曲線攻撃の対象となります[Jager2015]。
* Implementations MUST support and prefer to negotiate cipher suites offering forward secrecy. However, TLS 1.2 implementations SHOULD NOT negotiate cipher suites based on ephemeral finite-field Diffie-Hellman key agreement (i.e., "TLS_DHE_*" suites). This is justified by the known fragility of the construction (see [RACCOON]) and the limitation around negotiation, including using [RFC7919], which has seen very limited uptake.
* 実装は、先進的な秘密を提供する暗号スイートの交渉をサポートし、好む必要があります。ただし、TLS 1.2の実装は、Ephemeral Finite-Field Diffie-Hellman Key契約（つまり、「TLS_DHE_*」スイート）に基づいて暗号スイートを交渉するべきではありません。これは、建設の既知の脆弱性（[アライグマ]を参照）と、非常に限られた摂取が見られた[RFC7919]の使用を含む交渉に関する制限によって正当化されます。
Rationale: Forward secrecy (sometimes called "perfect forward secrecy") prevents the recovery of information that was encrypted with older session keys, thus limiting how far back in time data can be decrypted when an attack is successful. See Sections 7.3 and 7.4 for a detailed discussion.
理論的根拠：フォワード秘密（「完全なフォワード秘密」と呼ばれることもあります）は、古いセッションキーで暗号化された情報の回復を防ぎ、したがって、攻撃が成功したときに時間内のデータを解読できる程度を制限します。詳細については、セクション7.3および7.4を参照してください。
Given the foregoing considerations, implementation and deployment of the following cipher suites is RECOMMENDED:
前述の考慮事項を考えると、次の暗号スイートの実装と展開をお勧めします。
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
* TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
As these are Authenticated Encryption with Associated Data (AEAD) algorithms [RFC5116], these cipher suites are supported only in TLS 1.2 and not in earlier protocol versions.
これらは関連データ（AEAD）アルゴリズム[RFC5116]を使用した認証された暗号化であるため、これらの暗号スイートはTLS 1.2でのみサポートされ、以前のプロトコルバージョンではありません。
Typically, to prefer these suites, the order of suites needs to be explicitly configured in server software. It would be ideal if server software implementations were to prefer these suites by default.
通常、これらのスイートを好むには、スイートの順序をサーバーソフトウェアで明示的に構成する必要があります。サーバーソフトウェアの実装がデフォルトでこれらのスイートを優先する場合が理想的です。
Some devices have hardware support for AES Counter Mode with CBC-MAC (AES-CCM) but not AES Galois/Counter Mode (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 these are out of scope entirely.
一部のデバイスは、CBC-MAC（AES-CCM）を備えたAESカウンターモードのハードウェアサポートを備えていますが、AES Galois/Counter Mode（AES-GCM）ではないため、暗号スイートに関する前述の推奨事項に従うことができません。公開キーの暗号化をまったくサポートしていないデバイスもありますが、これらは完全に範囲外です。
A cipher suite that operates in CBC (cipher block chaining) mode (e.g., TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) SHOULD NOT be used unless the encrypt_then_mac extension [RFC7366] is also successfully negotiated. This requirement applies to both client and server implementations.
CBC（暗号ブロックチェーン）モード（例：TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256）で動作する暗号スイートは、Encrypt_Then_Mac拡張機能[RFC7366]もうまく交渉されない限り使用しないでください。この要件は、クライアントとサーバーの実装の両方に適用されます。
When using ECDSA signatures for authentication of TLS peers, it is RECOMMENDED that implementations use the NIST curve P-256. In addition, to avoid predictable or repeated nonces (which could reveal the long-term signing key), it is RECOMMENDED that implementations implement "deterministic ECDSA" as specified in [RFC6979] and in line with the recommendations in [RFC8446].
TLSピアの認証にECDSA署名を使用する場合、実装はNIST曲線P-256を使用することをお勧めします。さらに、予測可能または繰り返しのノンース（長期署名キーが明らかになる可能性がある）を回避するために、実装は[RFC6979]で指定された「決定論的ECDSA」を実装し、[RFC8446]の推奨事項に沿って実装することをお勧めします。
Note that implementations of "deterministic ECDSA" may be vulnerable to certain side-channel and fault injection attacks precisely because of their determinism. While most fault injection attacks described in the literature assume physical access to the device (and therefore are more relevant in Internet of Things (IoT) deployments with poor or non-existent physical security), some can be carried out remotely [Poddebniak2017], e.g., as Rowhammer [Kim2014] variants. In deployments where side-channel attacks and fault injection attacks are a concern, implementation strategies combining both randomness and determinism (for example, as described in [CFRG-DET-SIGS]) can be used to avoid the risk of successful extraction of the signing key.
「決定論的ECDSA」の実装は、特定のサイドチャネルおよび断層注入攻撃に対して正確に脆弱である可能性があることに注意してください。文献に記載されているほとんどの断層注入攻撃は、デバイスへの物理的アクセスを想定していますが（したがって、物理的なセキュリティが不十分または存在しない、または存在しない物理的セキュリティを備えたモノのインターネット（IoT）展開でより関連性があります）が、リモートで実行できる[Poddebniak2017]、例えば、Rowhammer [Kim2014]バリアントとして。サイドチャネル攻撃と断層インジェクション攻撃が懸念事項である展開では、ランダム性と決定論の両方を組み合わせた実装戦略（たとえば、[CFRG-det-sigs]に記載されているように）を使用して、署名の抽出の成功のリスクを回避できます。鍵。
Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server. 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.
クライアントは、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256を任意のサーバーへの最初の提案として含める必要があります。サーバーは、最初の提案ではない場合でも、提案されたときはいつでも、この暗号スイートを弱い暗号スイートよりも好む必要があります。もちろん、クライアントはより強力な暗号スイートを無料で提供できます。たとえば、AES-256を使用しています。彼らがそうする場合、サーバーは、それ以外の場合は、説得力のある理由（たとえば、真剣に劣化したパフォーマンス）がない限り、より強力な暗号スイートを好む必要があります。
The previous version of the TLS recommendations [RFC7525] implicitly allowed the old RFC 5246 mandatory-to-implement cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA. At the time of writing, this cipher suite does not provide additional interoperability, except with very old clients. As with other cipher suites that do not provide forward secrecy, implementations SHOULD NOT support this cipher suite. Other application protocols specify other cipher suites as mandatory to implement (MTI).
TLS推奨事項[RFC7525]の以前のバージョンは、古いRFC 5246の補充の包括的な暗号スイート、TLS_RSA_WITH_AES_128_CBC_SHAを暗黙的に許可しました。執筆時点では、この暗号スイートは、非常に古いクライアントを除き、追加の相互運用性を提供しません。前向きな秘密を提供しない他の暗号スイートと同様に、実装はこの暗号スイートをサポートすべきではありません。他のアプリケーションプロトコルは、実装するための必須として他の暗号スイートを指定します（MTI）。
[RFC8422] allows clients and servers to negotiate ECDH parameters (curves). Both clients and servers SHOULD include the "Supported Elliptic Curves Extension" [RFC8422]. Clients and servers SHOULD support the NIST P-256 (secp256r1) [RFC8422] and X25519 (x25519) [RFC7748] curves. Note that [RFC8422] deprecates all but the uncompressed point format. Therefore, if the client sends an ec_point_formats extension, the ECPointFormatList MUST contain a single element, "uncompressed".
[RFC8422]により、クライアントとサーバーがECDHパラメーター（曲線）をネゴシエートすることができます。クライアントとサーバーの両方に、「サポートされている楕円曲線拡張」[RFC8422]を含める必要があります。クライアントとサーバーは、NIST P-256（SECP256R1）[RFC8422]およびX25519（X25519）[RFC7748]曲線をサポートする必要があります。[RFC8422]は、非圧縮ポイント形式を除くすべてを非難することに注意してください。したがって、クライアントがEC_POINT_FORMATS拡張機能を送信する場合、ECPOINTFORMATLISTには単一の要素「非圧縮」を含める必要があります。
This document does not specify any cipher suites for TLS 1.3. Readers are referred to Section 9.1 of [RFC8446] for cipher suite recommendations.
このドキュメントでは、TLS 1.3の暗号スイートは指定されていません。読者は、暗号スイートの推奨については、[RFC8446]のセクション9.1を参照されます。
All ciphers have an upper limit on the amount of traffic that can be securely protected with any given key. In the case of AEAD cipher suites, two separate limits are maintained for each key:
すべての暗号には、特定のキーで安全に保護できるトラフィックの量に上限があります。AEAD暗号スイートの場合、各キーに対して2つの別々の制限が維持されます。
1. Confidentiality limit (CL), i.e., the number of records that can be encrypted.
1. 機密性制限（CL）、つまり、暗号化できるレコードの数。
2. Integrity limit (IL), i.e., the number of records that are allowed to fail authentication.
2. 整合性制限（IL）、つまり、認証に失敗することが許可されているレコードの数。
The latter applies to DTLS (and also to QUIC) but not to TLS itself, since TLS connections are torn down on the first decryption failure.
後者は、TLS接続が最初の復号化障害で取り壊されるため、DTLS（およびQUIC）に適用されますが、TLS自体には適用されません。
When a sender is approaching CL, the implementation SHOULD initiate a new handshake (in TLS 1.3, this can be achieved by sending a KeyUpdate message on the established session) to rotate the session key. When a receiver has reached IL, the implementation SHOULD close the connection. Although these recommendations are a best practice, implementers need to be aware that it is not always easy to accomplish them in protocols that are built on top of TLS/DTLS without introducing coordination across layer boundaries. See Section 6 of [RFC9001] for an example of the cooperation that was necessary in QUIC between the crypto and transport layers to support key updates. Note that in general, application protocols might not be able to emulate that method given their more constrained interaction with TLS/DTLS. As a result of these complexities, these recommendations are not mandatory.
送信者がCLに近づいている場合、実装は新しい握手を開始する必要があります（TLS 1.3では、これは確立されたセッションでキーアップデートメッセージを送信することで実現できます）。セッションキーを回転させます。受信者がILに到達した場合、実装は接続を閉じる必要があります。これらの推奨事項はベストプラクティスですが、実装者は、レイヤー境界を越えて調整を導入することなく、TLS/DTLの上に構築されたプロトコルでそれらを達成することが必ずしも容易ではないことを認識する必要があります。キーアップデートをサポートするために、暗号と輸送層の間でQUICで必要な協力の例については、[RFC9001]のセクション6を参照してください。一般に、アプリケーションプロトコルは、TLS/DTLとのより制約のある相互作用を考えると、その方法をエミュレートできない可能性があることに注意してください。これらの複雑さの結果、これらの推奨事項は必須ではありません。
For all TLS 1.3 cipher suites, readers are referred to Section 5.5 of [RFC8446] for the values of CL and IL. For all DTLS 1.3 cipher suites, readers are referred to Section 4.5.3 of [RFC9147].
すべてのTLS 1.3暗号スイートについて、読者はClとILの値について[RFC8446]のセクション5.5を参照されます。すべてのDTLS 1.3暗号スイートについて、読者は[RFC9147]のセクション4.5.3を参照されます。
For all AES-GCM cipher suites recommended for TLS 1.2 and DTLS 1.2 in this document, CL can be derived by plugging the corresponding parameters into the inequalities in Section 6.1 of [AEAD-LIMITS] that apply to random, partially implicit nonces, i.e., the nonce construction used in TLS 1.2. Although the obtained figures are slightly higher than those for TLS 1.3, it is RECOMMENDED that the same limit of 2^24.5 records is used for both versions.
このドキュメントでは、TLS 1.2およびDTLS 1.2に推奨されるすべてのAES-GCM暗号スイートについて、CLは、ランダムな部分的に暗黙の非能力に適用される[AEADリミット]のセクション6.1の不平等に対応するパラメーターをプラグすることで導き出すことができます。TLS 1.2で使用される非CE構造。取得した数値はTLS 1.3の数値よりもわずかに高いですが、2^24.5の同じ制限が両方のバージョンに使用されることをお勧めします。
For all AES-GCM cipher suites recommended for DTLS 1.2, IL (obtained from the same inequalities referenced above) is 2^28.
DTLS 1.2に推奨されるすべてのAES-GCM暗号スイートについて、IL（上記と同じ不平等から得られた）は2^28です。
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キー契約とサーバー認証用です。クライアント証明書が使用される場合、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 REQUIRED.
モジュラー指数（MODP）diffie-hellmanグループ（ "dhe" cipher suites）に基づいたキー交換では、少なくとも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]. A DH key of 2048 bits (equivalent to a 112-bit symmetric key) is the minimum allowed by the latest revision of [NIST.SP.800-56A] as of this writing (see in particular Appendix D of that document).
根拠：さまざまな理由で、実際には、DHキーは通常、2つのパワーである長さで生成されます（例：2^10 = 1024ビット、2^11 = 2048ビット、2^12 = 4096ビット）。1228ビットのDHキーは、80ビットの対称キー[RFC3766]にほぼ同等であるため、暗号スイートの「DHE」ファミリーのキーよりも長くキーを使用する方が良いです。1926ビットのDHキーは、100ビット対称キー[RFC3766]とほぼ同等です。2048ビットのDHキー（112ビット対称キーに相当）は、この記述時点で[nist.sp.800-56a]の最新の改訂で許可されている最小値です（その文書の特に付録Dを参照）。
As noted in [RFC3766], correcting for the emergence of The Weizmann Institute Relation Locator (TWIRL) machine [TWIRL] would imply that 1024-bit DH keys yield about 61 bits of equivalent strength and that a 2048-bit DH key would yield about 92 bits of equivalent strength. The Logjam attack [Logjam] further demonstrates that 1024-bit Diffie-Hellman parameters should be avoided.
[RFC3766]で述べたように、Weizmann Institute Relation Locator（Twirl）Machine [Twirl]の出現を修正すると、1024ビットDHキーが約61ビットの等価強度を生み、2048ビットDHキーが得られることを意味します。92ビットの同等の強度。logjam攻撃[Logjam]は、1024ビットのdiffie-hellmanパラメーターを避けるべきであることをさらに示しています。
With regard to ECDH keys, implementers are referred to the IANA "TLS Supported Groups" registry (formerly known as the "EC Named Curve Registry") within the "Transport Layer Security (TLS) Parameters" registry [IANA_TLS] and in particular to the "recommended" groups. Curves of less than 224 bits MUST NOT be used. This recommendation is in line with the latest revision of [NIST.SP.800-56A].
ECDHキーに関して、実装者は、「トランスポートレイヤーセキュリティ（TLS）パラメーター」レジストリ[IANA_TLS]、特に「推奨」グループ。224ビット未満の曲線を使用しないでください。この推奨事項は、[nist.sp.800-56a]の最新の改訂と一致しています。
When using RSA, servers MUST 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 and SHA-1 or MD5 MUST NOT be used [RFC9155] (for more details, see also [CAB-Baseline], for which the current version at the time of writing is 1.8.4). Clients MUST indicate to servers that they request SHA-256 by using the "Signature Algorithms" extension defined in TLS 1.2. For TLS 1.3, the same requirement is already specified by [RFC8446].
RSAを使用する場合、サーバーは、公開キーに少なくとも2048ビットモジュラスの証明書を使用して認証する必要があります。さらに、SHA-256ハッシュアルゴリズムの使用が推奨され、SHA-1またはMD5を使用してはいけません[RFC9155]（詳細については、[Cab-Baseline]も参照してください。1.8.4）。クライアントは、TLS 1.2で定義されている「署名アルゴリズム」拡張機能を使用して、SHA-256を要求することをサーバーに示す必要があります。TLS 1.3の場合、同じ要件が[RFC8446]によってすでに指定されています。
Implementations MUST NOT use the Truncated HMAC Extension, defined in Section 7 of [RFC6066].
実装は、[RFC6066]のセクション7で定義されている切り捨てられた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で最も一般的に使用されるアプリケーションプロトコルの実装と展開に適用されます。例には、以下が含まれますが、これらに限定されません。
* Web software and services that wish to protect HTTP traffic with TLS.
* TLSでHTTPトラフィックを保護したいWebソフトウェアとサービス。
* Email software and services that wish to protect IMAP, Post Office Protocol version 3 (POP3), or SMTP traffic with TLS.
* IMAP、郵便局プロトコルバージョン3（POP3）、またはTLSを使用したSMTPトラフィックを保護したいソフトウェアとサービスにメールしてください。
* Instant-messaging software and services that wish to protect Extensible Messaging and Presence Protocol (XMPP) or Internet Relay Chat (IRC) traffic with TLS.
* 拡張可能なメッセージとプレゼンスプロトコル（XMPP）またはTLSを使用したインターネットリレーチャット（IRC）トラフィックを保護したいインスタントメッシングソフトウェアとサービス。
* Realtime media software and services that wish to protect Secure Realtime Transport Protocol (SRTP) traffic with DTLS.
* DTLSを使用した安全なリアルタイムトランスポートプロトコル（SRTP）トラフィックを保護したいリアルタイムメディアソフトウェアとサービス。
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 [RFC7590], which updates [RFC6120]).
このドキュメントでは、TLSまたはDTLSを使用する既存のアプリケーションプロトコルによって規定されている実装および展開の推奨事項（例えば、必須の暗号スイートなど）を変更しません。そのようなアプリケーションプロトコルを使用するコミュニティが、ここで推奨されるベストプラクティスと一致するようにTLSまたはDTLの使用を近代化することを希望する場合、既存のアプリケーションプロトコル定義を明示的に更新する必要があります（1つの例は[RFC7590]です[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]を通じて開発された新しいアプリケーションプロトコルの設計者は、そのような適合を妨げる説得力のある理由の文書を提供しない限り、ここで推奨されるベストプラクティスに最低限に準拠することが期待されます（例えば、サポートを欠く制約付きデバイスへの広範な展開必要なアルゴリズムの場合）。
Although many of the recommendations provided here might also apply to QUIC insofar that it uses the TLS 1.3 handshake protocol, QUIC and other such secure transport protocols are out of scope of this document. For QUIC specifically, readers are referred to Section 9.2 of [RFC9001].
ここで提供される推奨事項の多くは、TLS 1.3ハンドシェイクプロトコルを使用する限り、QUICにも適用される場合がありますが、QUICおよびその他の安全な輸送プロトコルはこのドキュメントの範囲外ではありません。具体的には、読者は[RFC9001]のセクション9.2を参照されます。
This document does not address the use of TLS in constrained-node networks [RFC7228]. For recommendations regarding the profiling of TLS and DTLS for small devices with severe constraints on power, memory, and processing resources, the reader is referred to [RFC7925] and [IOT-PROFILE].
このドキュメントでは、制約付きノードネットワークでのTLSの使用には対処されていません[RFC7228]。パワー、メモリ、および処理リソースに厳しい制約を伴う小さなデバイスのTLSおよびDTLのプロファイリングに関する推奨事項については、読者は[RFC7925]および[IoTプロファイル]と呼ばれます。
This document provides recommendations for an audience that wishes to secure their communication with TLS to achieve the following:
このドキュメントは、以下を達成するためにTLSとのコミュニケーションを確保したい聴衆に推奨事項を提供します。
Confidentiality: all application-layer communication is encrypted with the goal that no party should be able to decrypt it except the intended receiver.
機密性：すべてのアプリケーション層通信は、意図したレシーバーを除く当事者がそれを解読できないという目標とともに暗号化されます。
Data integrity: any changes made to the communication in transit are detectable by the receiver.
データの整合性：輸送中の通信に加えられた変更は、受信者が検出できます。
Authentication: an endpoint of the TLS communication is authenticated as the intended entity to communicate with.
認証：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 requires 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 clients.
このドキュメントは、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. 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.
これらのシナリオでは、このドキュメントの推奨事項のいくつかは、それらを順守することはクリアテキストにフォールバックを引き起こす可能性があるため、あまりにも厳しいかもしれません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
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. The reader is referred to the Security Considerations sections of TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], TLS 1.2 [RFC5246], and DTLS 1.2 [RFC6347] for further context.
このドキュメント全体では、TLSプロトコルを使用してアプリケーションに直接影響するセキュリティプラクティスについて説明します。このセクションには、TLSと組み合わせて使用されるテクノロジーに関連するより広範なセキュリティ上の考慮事項が含まれています。読者は、TLS 1.3 [RFC8446]、DTLS 1.3 [RFC9147]、TLS 1.2 [RFC5246]、およびDTLS 1.2 [RFC6347]のセキュリティに関するセクションセクションを参照してください。
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 Sections 4.3.3, 4.3.4, and 4.3.5 of [RFC9110].
ホスト名の検証に関する要件（一般に、TLSレイヤーとその上に実行されるプロトコル間の結合）に関する要件は、プロトコルによって異なることが異なります。HTTPSの場合、これらの要件は[RFC9110]のセクション4.3.3、4.3.4、および4.3.5で定義されます。
Host name validation is security-critical for all common TLS use cases. Without it, TLS ensures that the certificate is valid and guarantees possession of the private key but does not ensure that the connection terminates at the desired endpoint. 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 application protocols, some of which implement a policy very different from HTTPS.
ホスト名の検証は、すべての一般的なTLSユースケースに対してセキュリティが批判的です。それがなければ、TLSは証明書が有効であることを保証し、秘密鍵の所有を保証しますが、接続が目的のエンドポイントで終了することを保証しません。読者は、TLSコンテキストでの汎用ホスト名の検証に関する詳細については、[RFC6125]を参照してください。さらに、RFCにはアプリケーションプロトコルの長いリストが含まれており、その一部はHTTPSとは非常に異なるポリシーを実装しています。
If the host name is discovered indirectly and insecurely (e.g., by a cleartext DNS query for an SRV or Mail Exchange (MX) 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 [RFC7673] and [RFC7672]).
ホスト名が間接的かつ不安に発見された場合（たとえば、SRVまたはメール交換（MX）レコードのクリアテキストDNSクエリによって）、提示された証明書と一致していても、参照識別子[RFC6125]として使用しないでください。この条件は、ホスト名が安全に発見された場合は適用されません（詳細については、[RFC7673]および[RFC7672]を参照）。
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].
ホスト名の検証は、通常、Leaf "End Entity"証明書にのみ適用されます。当然のことながら、PKIのコンテキストで適切な認証を確保するために、アプリケーションクライアントは[RFC5280]に従って認証パス全体を検証する必要があります。
Section 4.2 recommends the use of the AES-GCM authenticated encryption algorithm. Please refer to Section 6 of [RFC5288] for security considerations that apply specifically to AES-GCM when used with TLS.
セクション4.2では、AES-GCM認証暗号化アルゴリズムの使用を推奨します。TLSで使用した場合に特にAES-GCMに適用されるセキュリティ上の考慮事項については、[RFC5288]のセクション6を参照してください。
The existence of deployed TLS stacks that mistakenly reuse the AES-GCM nonce is documented in [Boeck2016], showing there is an actual risk of AES-GCM getting implemented insecurely and thus making TLS sessions that use an AES-GCM cipher suite vulnerable to attacks such as [Joux2006]. (See [CVE] records: CVE-2016-0270, CVE-2016-10213, CVE-2016-10212, and CVE-2017-5933.)
AES-GCM NonCeを誤って再利用する展開されたTLSスタックの存在は[Boeck2016]に文書化されており、AES-GCMが不安定に実装され、AES-GCM cipherスイートを使用する攻撃に対して脆弱なTLSセッションを作成する実際のリスクがあることを示しています。[joux2006]など。（[CVE] Records：CVE-2016-0270、CVE-2016-10213、CVE-2016-10212、およびCVE-2017-5933を参照してください。）
While this problem has been fixed in TLS 1.3, which enforces a deterministic method to generate nonces from record sequence numbers and shared secrets for all its AEAD cipher suites (including AES-GCM), TLS 1.2 implementations could still choose their own (potentially insecure) nonce generation methods.
この問題はTLS 1.3で修正されていますが、これはすべてのAEAD暗号スイート（AES-GCMを含む）のレコードシーケンス番号と共有秘密からノンセスを生成する決定論的方法を強制しますが、TLS 1.2実装はまだ独自の選択（潜在的に不安定な）を選択できます。NonCe生成方法。
It is therefore RECOMMENDED that TLS 1.2 implementations use the 64-bit sequence number to populate the nonce_explicit part of the GCM nonce, as described in the first two paragraphs of Section 5.3 of [RFC8446]. This stronger recommendation updates Section 3 of [RFC5288], which specifies that the use of 64-bit sequence numbers to populate the nonce_explicit field is optional.
したがって、TLS 1.2の実装は、64ビットシーケンス番号を使用して、[RFC8446]のセクション5.3の最初の2つの段落で説明されているように、GCM NonCEのNonCE_Explicit部分を埋めることをお勧めします。この強力な推奨事項は、[RFC5288]のセクション3を更新します。これは、nonCE_Explicitフィールドに入力するための64ビットシーケンス番号の使用がオプションであることを指定しています。
We note that at the time of writing, there are no cipher suites defined for nonce-reuse-resistant algorithms such as AES-GCM-SIV [RFC8452].
執筆時点では、AES-GCM-SIV [RFC8452]などの非耐性耐性アルゴリズム用に定義された暗号スイートはないことに注意してください。
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.
Forward Secrecy（「Perfect Forward Secrecy」または「PFS」とも呼ばれ、[RFC4949]で定義されている）は、セッションキーが通信当事者の長期キーとのみ暗号化された暗号化された会話を記録する攻撃者に対する防御です。
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:
TLSとDTLSのコンテキストでは、長期キーのこのような妥協は完全に信じられないわけではありません。たとえば、次のために発生する可能性があります。
* A client or server being attacked by some other attack vector, and the private key retrieved.
* 他のいくつかの攻撃ベクトルによって攻撃されているクライアントまたはサーバー、および秘密キーが取得されました。
* A long-term key retrieved from a device that has been sold or otherwise decommissioned without prior wiping.
* 事前の拭き取りなしに販売または廃止されたデバイスから取得された長期キー。
* A long-term key used on a device as a default key [Heninger2012].
* デバイスでデフォルトのキーとして使用される長期キー[Heninger2012]。
* A key generated by a trusted third party like a CA and later retrieved from it by either extortion or compromise [Soghoian2011].
* CAのような信頼できる第三者によって生成され、後に恐torまたは妥協のいずれかによってそれから取得されたキー[Soghoian2011]。
* A cryptographic breakthrough or the use of asymmetric keys with insufficient length [Kleinjung2010].
* 暗号化のブレークスルーまたは長さが不十分な非対称キーの使用[Kleinjung2010]。
* Social engineering attacks against system administrators.
* システム管理者に対するソーシャルエンジニアリング攻撃。
* Collection of private keys from inadequately protected backups.
* 保護されていないバックアップからのプライベートキーのコレクション。
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 arithmetic. Given the current state of the art, Elliptic Curve Diffie-Hellman appears to be more efficient, permits shorter key lengths, and allows less freedom for implementation errors than finite-field Diffie-Hellman.
一般に、フォワードの秘密は、Diffie-Hellmanスキームを使用してセッションキーを導き出すことによって達成されます。Diffie-Hellmanスキームは、両当事者が私的な秘密を維持し、特定の循環グループのモジュラーパワーとしてネットワーク上にパラメーターを送信します。いわゆる離散対数問題（DLP）の特性により、当事者は盗聴者がそうすることなくセッションキーを導き出すことができます。現在、十分に大きなパラメーターが選択されている場合、DLPに対する既知の攻撃はありません。Diffie-Hellmanスキームのバリアントは、最初に提案されたモジュラー算術の代わりに楕円曲線を使用します。現在の最先端を考えると、楕円曲線のdiffie-hellmanはより効率的であり、キーの長さが短くなり、有限フィールドの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, it is not uncommon for TLS implementations to 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 Exponentsを再利用することは珍しくありません。このような再利用は、主要なセキュリティの問題をもたらす可能性があります。
* If exponents are reused for too long (in some cases, even as little as 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.
* 指数があまりにも長く再利用されている場合（場合によっては、わずか数時間であっても）、ホストにアクセスする攻撃者は以前の接続を復号化できます。言い換えれば、指数の再利用は、前方の秘密の影響を無効にします。
* 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, although general guidance in this area is provided by [NIST.SP.800-56A] and available in many protocol implementations.
* 指数を再利用するTLS実装は、いくつかの既知の攻撃を回避するために、グループメンバーシップのために受け取ったDH公開キーをテストする必要があります。これらのテストは、執筆時点でTLSで標準化されていませんが、この分野の一般的なガイダンスは[nist.sp.800-56a]によって提供され、多くのプロトコル実装で利用可能です。
* Under certain conditions, the use of static finite-field DH keys, or of ephemeral finite-field DH keys that are reused across multiple connections, can lead to timing attacks (such as those described in [RACCOON]) on the shared secrets used in Diffie-Hellman key exchange.
* 特定の条件下では、静的有限フィールドDHキー、または複数の接続で再利用される短命の有限フィールドDHキーの使用は、使用される共有秘密のタイミング攻撃（[RACCOON]に記載されているものなど）につながる可能性があります。diffie-hellmanキーエクスチェンジ。
* An "invalid curve" attack can be mounted against Elliptic Curve DH if the victim does not verify that the received point lies on the correct curve. If the victim is reusing the DH secrets, the attacker can repeat the probe varying the points to recover the full secret (see [Antipa2003] and [Jager2015]).
* 被害者が受信ポイントが正しい曲線にあることを確認しない場合、「無効な曲線」攻撃は楕円曲線DHに対して取り付けることができます。被害者がDHの秘密を再利用している場合、攻撃者はポイントを変化させるプローブを繰り返して、完全な秘密を回復することができます（[antipa2003]および[jager2015]を参照）。
To address these concerns:
これらの懸念に対処するには：
* TLS implementations SHOULD NOT use static finite-field DH keys and SHOULD NOT reuse ephemeral finite-field DH keys across multiple connections.
* TLSの実装は、静的な有限フィールドDHキーを使用しないでください。また、複数の接続にわたって一時的な有限フィールドDHキーを再利用しないでください。
* Server implementations that want to reuse Elliptic Curve DH keys SHOULD either use a "safe curve" [SAFECURVES] (e.g., X25519) or perform the checks described in [NIST.SP.800-56A] on the received points.
* 楕円曲線DHキーを再利用したいサーバーの実装DHキーは、「安全な曲線」[セーフケルブ]（例えば、x25519）を使用するか、受信ポイントの[nist.sp.800-56a]に記載されているチェックを実行する必要があります。
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]をチェックするために、完全かつ効率的なソリューションが存在しない場合でも、以下の考慮事項と推奨事項は、証明書の取り消しに関する現在の最新技術を表しています。
* Certificate revocation is an important tool when recovering from attacks on the TLS implementation as well as cases of misissued certificates. TLS implementations MUST implement a strategy to distrust revoked certificates.
* 証明書の取り消しは、TLS実装への攻撃から回復する際の重要なツールと、誤った証明書の場合です。TLS実装は、取り消された証明書を信頼する戦略を実装する必要があります。
* 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. The more modern [CRLite] and the follow-on Let's Revoke [LetsRevoke] build on the availability of Certificate Transparency [RFC9162] logs and aggressive compression to allow practical use of the CRL infrastructure, but at the time of writing, neither solution is deployed for client-side revocation processing at scale.
* 証明書の取り消しリスト（CRL）は、取り消し情報を配布するための最も広くサポートされているメカニズムですが、分割されたCRLやデルタCRLなどの回避策にもかかわらず、それらの有用性を制限するスケーリングの課題を知っています。より近代的な[crlite]と後続のレッツオーク[Letsrevoke]は、証明書の透明性[RFC9162]ログと積極的な圧縮の可用性に基づいて構築されています。大規模なクライアント側の失効処理用。
* Proprietary mechanisms that embed revocation lists in the web browser's configuration database cannot scale beyond the few most heavily used web servers.
* Webブラウザーの構成データベースに取り消しリストを埋め込んだ独自のメカニズムは、最も多く使用されている少数のWebサーバーを超えて拡張することはできません。
* The Online Certification Status Protocol (OCSP) [RFC6960] in its basic form 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.) For a recent survey of the status of OCSP deployment in the web PKI, see [Chung18].
* その基本形式のオンライン認証ステータスプロトコル（OCSP）[RFC6960]は、スケーリングとプライバシーの両方の問題を示しています。さらに、クライアントは通常、「ソフトフェイル」です。つまり、OCSPサーバーが応答しない場合、TLS接続を中止しないことを意味します。（ただし、これはOCSPレスポンダーがオフラインになった場合のサービス拒否攻撃を回避するための回避策かもしれません。）Web PKIでのOCSP展開の状態に関する最近の調査については、[Chung18]を参照してください。
* 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 an active on-path attacker because the attacker can simply ignore the client's request for a stapled OCSP response.
* 一般に「OCSPステープリング」と呼ばれるTLS証明書ステータス要求拡張機能（[RFC6066]のセクション8）は、OCSPの運用上の問題を解決します。ただし、攻撃者はクライアントのホチュリオンのOCSP応答に対する要求を単純に無視できるため、アクティブなオンパス攻撃者の存在下ではまだ効果がありません。
* [RFC7633] defines a certificate extension that indicates that clients must expect stapled OCSP responses for the certificate and must abort the handshake ("hard-fail") if such a response is not available.
* [RFC7633]は、クライアントが証明書のステープル型OCSP応答を期待し、そのような応答が利用できない場合はハンドシェイク（「ハードフェイル」）を中止する必要があることを示す証明書延長を定義します。
* OCSP stapling as used in TLS 1.2 does not extend to intermediate certificates within a certificate chain. The Multiple Certificate Status extension [RFC6961] addresses this shortcoming, but it has seen little deployment and had been deprecated by [RFC8446]. As a result, although this extension was recommended for TLS 1.2 in [RFC7525], it is no longer recommended by this document.
* TLS 1.2で使用されているOCSPステープリングは、証明書チェーン内の中間証明書に拡張されません。複数の証明書ステータス拡張[RFC6961]はこの欠点に対処していますが、展開はほとんどなく、[RFC8446]によって非難されていました。その結果、[RFC7525]のTLS 1.2にはこの拡張機能が推奨されていましたが、このドキュメントでは推奨されなくなりました。
* TLS 1.3 (Section 4.4.2.1 of [RFC8446]) allows the association of OCSP information with intermediate certificates by using an extension to the CertificateEntry structure. However, using this facility remains impractical because many certification authorities (CAs) either do not publish OCSP for CA certificates or publish OCSP reports with a lifetime that is too long to be useful.
* TLS 1.3（[RFC8446]のセクション4.4.2.1）により、OCSP情報との関連付けは、拡張子をCertificateEntry構造に使用することにより、中間証明書との関連を許可します。ただし、多くの認証当局（CA）はCA証明書用のOCSPを公開していないか、有用になるには長すぎるOCSPレポートを生涯で公開していないため、この施設を使用することは非現実的なままです。
* Both CRLs and OCSP depend on relatively reliable connectivity to the Internet, which might not be available to certain kinds of nodes. A common example is newly provisioned devices that need to establish a secure connection in order to boot up for the first time.
* CRLとOCSPの両方は、特定の種類のノードでは利用できない可能性があるインターネットへの比較的信頼性の高い接続に依存しています。一般的な例は、初めて起動するために安全な接続を確立する必要がある新しくプロビジョニングされたデバイスです。
For the common use cases of public key certificates in TLS, 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: OCSP [RFC6960] and OCSP stapling using the status_request extension defined in [RFC6066]. Note that the exact mechanism for embedding the status_request extension differs between TLS 1.2 and 1.3. As a matter of local policy, server operators MAY request that CAs issue must-staple [RFC7633] certificates for the server and/or for client authentication, but we recommend reviewing the operational conditions before deciding on this approach.
TLSの公開キー証明書の一般的なユースケースの場合、サーバーは、現在の最先端を考慮して、可能な将来のソリューションの基礎として、ベストプラクティスとして以下をサポートする必要があります：OCSP [RFC6960]およびStatus_Request拡張機能を使用したOCSPステープリングは定義されています[RFC6066]。Status_Request拡張機能を埋め込むための正確なメカニズムは、TLS 1.2と1.3の間で異なることに注意してください。ローカルポリシーの問題として、サーバーオペレーターは、CASの問題がサーバーおよび/またはクライアント認証の証明書を作成する必要がある[RFC7633]マストステープル[RFC7633]を要求することができますが、このアプローチを決定する前に運用条件を確認することをお勧めします。
The considerations in this section do not apply to scenarios where the DNS-Based Authentication of Named Entities (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]のDNSベースの認証が、サーバーがTLS接続に有効かつ適切であると考える証明書をクライアントに通知するために使用されるシナリオには適用されません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://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, <https://www.rfc-editor.org/info/rfc3766>.
[RFC3766] Orman、H。およびP. Hoffman、「対称キーの交換に使用されるパブリックキーの強度の決定」、BCP 86、RFC 3766、DOI 10.17487/RFC3766、2004年4月、<https：//www.rfc-editor。org/info/rfc3766>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、DOI 10.17487/RFC5246、2008年8月、<https://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, DOI 10.17487/RFC5288, August 2008, <https://www.rfc-editor.org/info/rfc5288>.
[RFC5288] Salowey、J.、Choudhury、A。、およびD. McGrew、「AES Galois Counter Mode（GCM）Cipher Suites for TLS」、RFC 5288、DOI 10.17487/RFC5288、2008年8月、<https：// www。rfc-editor.org/info/rfc5288>。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <https://www.rfc-editor.org/info/rfc5746>.
[RFC5746] Rescorla、E.、Ray、M.、Dispensa、S。、およびN. Oskov、「輸送層のセキュリティ（TLS）再交渉の表示拡張」、RFC 5746、DOI 10.17487/RFC5746、2010年2月、<HTTPS：//www.rfc-editor.org/info/rfc5746>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] EastLake 3rd、D。、「輸送層セキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487/RFC6066、2011年1月、<https://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, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「輸送層のセキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開キーインフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、RFC 6125、DOI 10.17487/RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6176] Turner、S。およびT. Polk、「Secure Sockets Layer（SSL）バージョン2.0を禁止する」、RFC 6176、DOI 10.17487/RFC6176、2011年3月、<https://www.rfc-editor.org/info/RFC6176>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「データグラムトランスポートレイヤーセキュリティバージョン1.2」、RFC 6347、DOI 10.17487/RFC6347、2012年1月、<https://www.rfc-editor.org/info/rfc6347>
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6979] Pornin、T。、「デジタル署名アルゴリズム（DSA）および楕円曲線デジタル署名アルゴリズム（ECDSA）の決定論的使用」、RFC 6979、DOI 10.17487/RFC6979、2013年8月、<https：//www.RFC-editor.org/info/rfc6979>。
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「輸送層セキュリティ（TLS）アプリケーション層プロトコル交渉拡張」、RFC 7301、DOI 10.17487/RFC7301、2014年7月、<https://www.rfc-editor.org/info/rfc7301>。
[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, <https://www.rfc-editor.org/info/rfc7366>.
[RFC7366] Gutmann、P。、「輸送層セキュリティ（TLS）およびデータグラム輸送層のセキュリティ（DTLS）のためのEncrypt-Then-Mac」、RFC 7366、DOI 10.17487/RFC7366、2014年9月、<https：//www.rfc-editor.org/info/rfc7366>。
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <https://www.rfc-editor.org/info/rfc7465>.
[RFC7465] Popov、A。、「RC4暗号スイートの禁止」、RFC 7465、DOI 10.17487/RFC7465、2015年2月、<https://www.rfc-editor.org/info/rfc7465>
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.
[RFC7627] Bhargavan、K.、Ed。、Delignat-Lavaud、A.、Pironti、A.、Langley、A.、およびM. Ray、「Transport Layer Security（TLS）セッションハッシュおよび拡張マスターシークレットエクステンション」、RFC7627、doi 10.17487/rfc7627、2015年9月、<https://www.rfc-editor.org/info/rfc7627>。
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748] Langley、A.、Hamburg、M。、およびS. Turner、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487/RFC7748、2016年1月、<https://www.rfc-editor.org/info/RFC7748>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8422] Nir、Y.、Josefsson、S。、およびM. Pegourie-Gonnard、「輸送層セキュリティ（TLS）バージョン（TLS）バージョン用の楕円曲線暗号化（ECC）暗号スイート」、RFC 8422、DOI 10.17487/RFC8422、2018年8月、<https://www.rfc-editor.org/info/rfc8422>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc846>
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.
[RFC8996] Moriarty、K。およびS. Farrell、「TLS 1.0およびTLS 1.1を非難する」、BCP 195、RFC 8996、DOI 10.17487/RFC8996、2021年3月、<https：//www.rfc-editor.org/info//RFC8996>。
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
[RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2", RFC 9155, DOI 10.17487/RFC9155, December 2021, <https://www.rfc-editor.org/info/rfc9155>.
[RFC9155] Velvindron、L.、Moriarty、K。、およびA. Ghedini、「TLS 1.2およびDTLS 1.2のMD5およびSHA-1シグネチャーハッシュを非難する」、RFC 9155、DOI 10.17487/RFC9155、2021年12月、<HTPS：/<HTPS：//www.rfc-editor.org/info/rfc9155>。
[AEAD-LIMITS] Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on AEAD Algorithms", Work in Progress, Internet-Draft, draft-irtf-cfrg-aead-limits-05, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-05>.
[Aead-limits]Günther、F.、Thomson、M.、およびC. A. Wood、「AEADアルゴリズムの使用制限」、Work in Progress、Internet-Draft、Draft-ARTF-CFRG-AEAD-LIMITS-05、2022年7月11日、<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-05>。
[ALPACA] Brinkmann, M., Dresen, C., Merget, R., Poddebniak, D., Müller, J., Somorovsky, J., Schwenk, J., and S. Schinzel, "ALPACA: Application Layer Protocol Confusion - Analyzing and Mitigating Cracks in TLS Authentication", 30th USENIX Security Symposium (USENIX Security 21), August 2021, <https://www.usenix.org/conference/usenixsecurity21/ presentation/brinkmann>.
[Alpaca] Brinkmann、M.、Dresen、C.、Merget、R.、Poddebniak、D.、Müller、J.、Somorovsky、J.、Schwenk、J。、およびS. Schinzel、 "Alpaca：アプリケーションレイヤープロトコル混乱-TLS認証の亀裂の分析と軽減」、第30回USENIXセキュリティシンポジウム（USENIX Security 21）、2021年8月、<https://www.usenix.org/conference/usenixsecurity21/ presention/brinkmann>。
[Antipa2003] Antipa, A., Brown, D. R. L., Menezes, A., Struik, R., and S. Vanstone, "Validation of Elliptic Curve Public Keys", Public Key Cryptography - PKC 2003, December 2003, <https://doi.org/10.1007/3-540-36288-6_16>.
[Antipa2003] Antipa、A.、A.、Brown、D。L.、Menezes、A.、Struik、R。、およびS. Vanstone、「楕円曲線パブリックキーの検証」、公共鍵暗号化-PKC 2003、2003年12月、<https：/ <https：//doi.org/10.1007/3-540-36288-6_16>。
[Boeck2016] Böck, H., Zauner, A., Devlin, S., Somorovsky, J., and P. Jovanovic, "Nonce-Disrespecting Adversaries: Practical Forgery Attacks on GCM in TLS", May 2016, <https://eprint.iacr.org/2016/475.pdf>.
[Boeck2016]Böck、H.、Zauner、A.、Devlin、S.、Somorovsky、J。、およびP. Jovanovic、「非容疑者：TLSのGCMに対する実用的な偽造攻撃」、2016年5月、<https：//eprint.iacr.org/2016/475.pdf>。
[CAB-Baseline] CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates", Version 1.8.4, April 2022, <https://cabforum.org/documents/>.
[Cab-Baseline] CA/ブラウザフォーラム、「公開証明書の発行と管理に関するベースライン要件」、バージョン1.8.4、2022年4月、<https://cabforum.org/documents/>。
[CFRG-DET-SIGS] Preuß Mattsson, J., Thormarker, E., and S. Ruohomaa, "Deterministic ECDSA and EdDSA Signatures with Additional Randomness", Work in Progress, Internet-Draft, draft-irtf-cfrg-det-sigs-with-noise-00, 8 August 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-det-sigs-with-noise-00>.
[CFRG-det-sigs]preußmattsson、J.、Thormarker、E。、およびS. ruohomaa、「追加のランダム性を備えた決定論的ECDSAおよびEDDSAシグネチャ」、進行中の作業、インターネットドラフト、ドラフト-ARTF-CFRG-DET-sigs-with-noise-00、2022年8月8日、<https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-det-sigs-with-noise-00>。
[Chung18] Chung, T., Lok, J., Chandrasekaran, B., Choffnes, D., Levin, D., Maggs, B., Mislove, A., Rula, J., Sullivan, N., and C. Wilson, "Is the Web Ready for OCSP Must-Staple?", Proceedings of the Internet Measurement Conference 2018, DOI 10.1145/3278532.3278543, October 2018, <https://doi.org/10.1145/3278532.3278543>.
[Chung18] Chung、T.、Lok、J.、Chandrasekaran、B.、Choffnes、D.、Levin、D.、Maggs、B.、Mislove、A.、Rula、J.、Sullivan、N。、およびC。ウィルソン、「WebはOCSPの準備ができている必要がありますか？」、インターネット測定会議2018の議事録、DOI 10.1145/3278532.3278543、2018年10月、<https://doi.org/10.1145/3278532.3278543>。
[CRLite] Larisch, J., Choffnes, D., Levin, D., Maggs, B., Mislove, A., and C. Wilson, "CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers", 2017 IEEE Symposium on Security and Privacy (SP), DOI 10.1109/sp.2017.17, May 2017, <https://doi.org/10.1109/sp.2017.17>.
[Crlite] Larisch、J.、Choffnes、D.、Levin、D.、Maggs、B.、Mislove、A。、およびC. Wilson、「Crlite：すべてのTLS取消しをすべてのブラウザーにプッシュするためのスケーラブルなシステム」、2017年セキュリティとプライバシーに関するIEEEシンポジウム（SP）、DOI 10.1109/SP.2017.17、2017年5月、<https://doi.org/10.1109/sp.2017.17>。
[CVE] MITRE, "Common Vulnerabilities and Exposures", <https://cve.mitre.org>.
[cve] Miter、「共通の脆弱性と露出」、<https://cve.mitre.org>。
[DegabrieleP07] Degabriele, J. and K. Paterson, "Attacking the IPsec Standards in Encryption-only Configurations", 2007 IEEE Symposium on Security and Privacy (SP '07), DOI 10.1109/sp.2007.8, May 2007, <https://doi.org/10.1109/sp.2007.8>.
[Degabrielep07] Degabriele、J。およびK. Paterson、「暗号化のみの構成におけるIPSEC標準の攻撃」、2007年のIEEE Symposium on Security and Privacy（SP '07）、DOI 10.1109/SP.2007.8、2007年5月、<https：//doi.org/10.1109/sp.2007.8>。
[DROWN] Aviram, N., Schinzel, S., Somorovsky, J., Heninger, N., Dankel, M., Steube, J., Valenta, L., Adrian, D., Halderman, J., Dukhovni, V., Käsper, E., Cohney, S., Engels, S., Paar, C., and Y. Shavitt, "DROWN: Breaking TLS using SSLv2", 25th USENIX Security Symposium (USENIX Security 16), August 2016, <https://www.usenix.org/conference/usenixsecurity16/ technical-sessions/presentation/aviram>.
[Drown] Aviram、N.、Schinzel、S.、Somorovsky、J.、Heninger、N.、Dankel、M.、Steube、J.、Valenta、L.、Adrian、D.、Halderman、J.、Dukhovni、V.、Käsper、E.、Cohney、S.、Engels、S.、Paar、C。、およびY. Shavitt、「Drown：SSLV2を使用してTLSを破る」、25th Usenix Security Symposium（Usenix Security 16）、2016年8月、<https://www.usenix.org/conference/usenixsecurity16/ technical-sessions/presention/aviram>。
[Heninger2012] Heninger, N., Durumeric, Z., Wustrow, E., and J. A. Halderman, "Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices", 21st Usenix Security Symposium, August 2012.
[Heninger2012] Heninger、N.、Durumeric、Z.、Wustrow、E.、およびJ. A. Halderman、「PSとQSのマイニング：ネットワークデバイスでの広範な弱い鍵の検出」、21st Usenix Security Symposium、2012年8月。
[IANA_TLS] IANA, "Transport Layer Security (TLS) Parameters", <https://www.iana.org/assignments/tls-parameters>.
[IANA_TLS] IANA、「トランスポートレイヤーセキュリティ（TLS）パラメーター」、<https://www.iana.org/assignments/tls-parameters>。
[IOT-PROFILE] Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for the Internet of Things", Work in Progress, Internet-Draft, draft-ietf-uta-tls13-iot-profile-05, 6 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-05>.
[IoT-Profile] Tschofenig、H。and T. Fossati、「TLS/DTLS 1.3モノのインターネットのプロファイル」、進行中の作業、インターネットドラフト、ドラフト-ITA-TLS13-ot-Profile-05、62022年7月、<https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-05>。
[Jager2015] Jager, T., Schwenk, J., and J. Somorovsky, "Practical Invalid Curve Attacks on TLS-ECDH", Computer Security -- ESORICS 2015, pp. 407-425, DOI 10.1007/978-3-319-24174-6_21, 2015, <https://doi.org/10.1007/978-3-319-24174-6_21>.
[Jager2015] Jager、T.、Schwenk、J。、およびJ. Somorovsky、「TLS-ECDHに対する実用的な曲線攻撃」、コンピューターセキュリティ-Esorics 2015、pp。407-425、doi 10.1007/978-3-319-24174-6_21、2015、<https://doi.org/10.1007/978-3-319-24174-6_21>。
[Joux2006] Joux, A., "Authentication Failures in NIST version of GCM", 2006, <https://csrc.nist.gov/csrc/media/projects/ block-cipher-techniques/documents/bcm/comments/800-38- series-drafts/gcm/joux_comments.pdf>.
[Joux2006] Joux、A。、「GCMのNISTバージョンの認証障害」、2006、<https://csrc.nist.gov/csrc/media/projects/ block-cipher-techniques/documents/bcm/comments/800-38-シリーズドラフト/gcm/joux_comments.pdf>。
[Kim2014] Kim, Y., Daly, R., Kim, J., Fallin, C., Lee, J. H., Lee, D., Wilkerson, C., Lai, K., and O. Mutlu, "Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors", DOI 10.1109/ISCA.2014.6853210, July 2014, <https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf>.
[Kim2014] Kim、Y.、Daly、R.、Kim、J.、Fallin、C.、Lee、J.H.、Lee、D.、Wilkerson、C.、Lai、K。、およびO. Mutlu、 "Flipping Bitsそれらにアクセスせずに記憶に残る：DRAM乱れエラーの実験的研究」、DOI 10.1109/ISCA.2014.6853210、2014年7月、<https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf>。
[Kleinjung2010] Kleinjung, T., Aoki, K., Franke, J., Lenstra, A., Thomé, E., Bos, J., Gaudry, P., Kruppa, A., Montgomery, P., Osvik, D., te Riele, H., Timofeev, A., and P. Zimmermann, "Factorization of a 768-Bit RSA Modulus", Advances in Cryptology - CRYPTO 2010, pp. 333-350, DOI 10.1007/978-3-642-14623-7_18, 2010, <https://doi.org/10.1007/978-3-642-14623-7_18>.
[Kleinjung2010] Kleinjung、T.、Aoki、K.、Franke、J.、Lenstra、A.、Thomé、E.、Bos、J.、Gaudry、P.、Kruppa、A.、Montgomery、P.、Osvik、D.、Te Riele、H.、Timofeev、A。、およびP. Zimmermann、「768ビットRSAモジュラスの因数分解」、Cryptogology-Crypto 2010、pp。333-350、doi 10.1007/978-3-642-14623-7_18、2010、<https://doi.org/10.1007/978-3-642-14623-7_18>。
[LetsRevoke] Smith, T., Dickinson, L., and K. Seamons, "Let's Revoke: Scalable Global Certificate Revocation", Proceedings 2020 Network and Distributed System Security Symposium, DOI 10.14722/ndss.2020.24084, February 2020, <https://doi.org/10.14722/ndss.2020.24084>.
[Letsrevoke] Smith、T.、Dickinson、L。、およびK. Seamons、「Let's evoke：Scalable Global Certificate recocation」、Proceedings 2020 Network and Distributed System Security Symposium、doi 10.14722/ndss.2020.24084、2月2020年、<https：//doi.org/10.14722/ndss.2020.24084>。
[Logjam] Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P., Green, M., Halderman, J., Heninger, N., Springall, D., Thomé, E., Valenta, L., VanderSloot, B., Wustrow, E., Zanella-Béguelin, S., and P. Zimmermann, "Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice", Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pp. 5-17, DOI 10.1145/2810103.2813707, October 2015, <https://doi.org/10.1145/2810103.2813707>.
[Logjam] Adrian、D.、Bhargavan、K.、Durumeric、Z.、Gaudry、P.、Green、M.、Halderman、J.、Heninger、N.、Springall、D.、Thomé、E.、Valenta、L.、Vandersloot、B.、Wustrow、E.、Zanella-Béguelin、S。、およびP. Zimmermann、「不完全な前方の秘密：実際のDiffie-Hellmanが実際に失敗する方法」、第22回ACM SIGSAC会議のコンピューターおよび通信会議の議事録セキュリティ、5-17ページ、DOI 10.1145/2810103.2813707、2015年10月、<https://doi.org/10.1145/28103.2813707>。
[Multiple-Encryption] Merkle, R. and M. Hellman, "On the security of multiple encryption", Communications of the ACM, Vol. 24, Issue 7, pp. 465-467, DOI 10.1145/358699.358718, July 1981, <https://doi.org/10.1145/358699.358718>.
[多重暗号] Merkle、R。およびM. Hellman、「複数の暗号化のセキュリティに関する」、ACMの通信、Vol。24、第7号、pp。465-467、DOI 10.1145/358699.358718、1981年7月、<https://doi.org/10.1145/358699.358718>。
[NIST.SP.800-56A] National Institute of Standards and Technology, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", Revision 3, NIST Special Publication 800-56A, DOI 10.6028/NIST.SP.800-56Ar3, April 2018, <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
[nist.sp.800-56a]国立標準技術研究所、「離散対数暗号化を使用したペアワイズのキー確立スキームの推奨」、リビジョン3、NIST Special Publication 800-56A、doi 10.6028/nist.sp.80000-56ar3、2018年4月、<https://doi.org/10.6028/nist.sp.800-56ar3>。
[PatersonRS11] Paterson, K., Ristenpart, T., and T. Shrimpton, "Tag Size Does Matter: Attacks and Proofs for the TLS Record Protocol", Proceedings of the 17th International conference on The Theory and Application of Cryptology and Information Security, pp. 372-389, DOI 10.1007/978-3-642-25385-0_20, December 2011, <https://doi.org/10.1007/978-3-642-25385-0_20>.
[Patersonrs11] Paterson、K.、Ristenpart、T。、およびT. Shrimpton、「タグのサイズは重要です：TLSレコードプロトコルの攻撃と証明」、第17回の国際会議と暗号学と情報セキュリティの適用に関する議事録の議事録、pp。372-389、doi 10.1007/978-3-642-25385-0_20、2011年12月、<https://doi.org/10.1007/978-3-642-25385-0_20>。
[Poddebniak2017] Poddebniak, D., Somorovsky, J., Schinzel, S., Lochter, M., and P. Rösler, "Attacking Deterministic Signature Schemes using Fault Attacks", Conference: 2018 IEEE European Symposium on Security and Privacy, DOI 10.1109/EuroSP.2018.00031, April 2018, <https://eprint.iacr.org/2017/1014.pdf>.
[Poddebniak2017] Poddebniak、D.、Somorovsky、J.、Schinzel、S.、Lochter、M。、およびP.Rösler、「断層攻撃を使用した決定論的な署名スキームの攻撃」、会議：2018 IEEE欧州シンポジウムセキュリティとプライバシー、DOII10.1109/EUROSP.2018.00031、2018年4月、<https://eprint.iacr.org/2017/1014.pdf>。
[POODLE] US-CERT, "SSL 3.0 Protocol Vulnerability and POODLE Attack", October 2014, <https://www.us-cert.gov/ncas/alerts/TA14-290A>.
[Poodle] US-Cert、「SSL 3.0プロトコルの脆弱性とPoodle Attack」、2014年10月、<https://www.us-cert.gov/ncas/alerts/ta14-290a>。
[RACCOON] Merget, R., Brinkmann, M., Aviram, N., Somorovsky, J., Mittmann, J., and J. Schwenk, "Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E)", 30th USENIX Security Symposium (USENIX Security 21), 2021, <https://www.usenix.org/conference/usenixsecurity21/ presentation/merget>.
[Raccoon] Merget、R.、Brinkmann、M.、Aviram、N.、Somorovsky、J.、Mittmann、J。、およびJ. Schwenk、「Raccoon Attack：TLSで最も有意なビットオークルの発見と悪用 - DH（E） "、30th Usenix Security Symposium（Usenix Security 21）、2021、<https://www.usenix.org/conference/usenixsecurity21/ Presention/Merget>。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.
[RFC2026] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、DOI 10.17487/RFC2026、1996年10月、<https://www.rfc-editor.org/info/rfc26>。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <https://www.rfc-editor.org/info/rfc2246>.
[RFC2246] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、DOI 10.17487/RFC2246、1999年1月、<https://www.rfc-editor.org/info/rfc2246>
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、DOI 10.17487/RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, DOI 10.17487/RFC3602, September 2003, <https://www.rfc-editor.org/info/rfc3602>.
[RFC3602]フランケル、S。、グレン、R。、およびS.ケリー、「AES-CBC暗号アルゴリズムとIPSECでの使用」、RFC 3602、DOI 10.17487/RFC3602、2003年9月、<https：// www。rfc-editor.org/info/rfc3602>。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.1」、RFC 4346、DOI 10.17487/RFC4346、2006年4月、<https://www.rfc-editor.org/info/RFC4346>。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, <https://www.rfc-editor.org/info/rfc4347>.
[RFC4347] Rescorla、E。およびN. Modadugu、「データグラム輸送層セキュリティ」、RFC 4347、DOI 10.17487/RFC4347、2006年4月、<https://www.rfc-editor.org/info/rfc4347>
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <https://www.rfc-editor.org/info/rfc4949>.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、FYI 36、RFC 4949、DOI 10.17487/RFC4949、2007年8月、<https://www.rfc-editor.org/info/rfc4949>
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「サーバー側の状態なしの輸送層セキュリティ（TLS）セッション再開」、RFC 5077、DOI 10.17487/RFC5077、2008年1月<https://www.rfc-editor.org/info/rfc5077>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェイスとアルゴリズム」、RFC 5116、DOI 10.17487/RFC5116、2008年1月、<https://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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、DOI 10.17487/RFC5321、2008年10月、<https://www.rfc-editor.org/info/rfc5321>。
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, <https://www.rfc-editor.org/info/rfc6101>.
[RFC6101] Freier、A.、Karlton、P。、およびP. Kocher、「Secure Sockets Layer（SSL）プロトコルバージョン3.0」、RFC 6101、DOI 10.17487/RFC6101、2011年8月、<https：//www.rfc-editor.org/info/rfc6101>。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「拡張可能なメッセージと存在プロトコル（XMPP）：Core」、RFC 6120、DOI 10.17487/RFC6120、2011年3月、<https://www.rfc-editor.org/info/rfc6120>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698] Hoffman、P。and J. Schlyter、「名前付きエンティティ（DANE）輸送層セキュリティ（TLS）プロトコルのDNSベースの認証」、TLSA：RFC 6698、DOI 10.17487/RFC6698、2012年8月、<HTTPS：//www.rfc-editor.org/info/rfc6698>。
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, November 2012, <https://www.rfc-editor.org/info/rfc6797>.
[RFC6797] Hodges、J.、Jackson、C。、およびA. Barth、「HTTP Strict Transport Security（HSTS）」、RFC 6797、DOI 10.17487/RFC6797、2012年11月、<https：//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, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、 "x.509インターネット公開キーインフラオンライン証明書ステータスプロトコル-OCSP"、RFC6960、doi 10.17487/rfc6960、2013年6月、<https://www.rfc-editor.org/info/rfc6960>。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC6961] Pettersen、Y。、「トランスポートレイヤーセキュリティ（TLS）複数の証明書ステータスリクエスト拡張機能」、RFC 6961、DOI 10.17487/RFC6961、2013年6月、<https://www.rfc-editor.org/info/RFC6961>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M。、およびA. Keranen、「制約ノードネットワークの用語」、RFC 7228、DOI 10.17487/RFC7228、2014年5月、<https://www.rfc-editor.org/info/rfc7228>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見的セキュリティ：ほとんどの場合、一部の保護」、RFC 7435、DOI 10.17487/RFC7435、2014年12月、<https://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, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「輸送層のセキュリティ（TLS）およびデータグラムTLS（DTLS）に関する既知の攻撃の要約」、DOI 10.17487/RFC7457、2015年2月、<https://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, DOI 10.17487/RFC7507, April 2015, <https://www.rfc-editor.org/info/rfc7507>.
[RFC7507] Moeller、B。およびA. Langley、「プロトコルダウングレード攻撃を防ぐためのTLSフォールバックシグナリング暗号スイート値（SCSV）、RFC 7507、DOI 10.17487/RFC7507、2015年4月、<https：//ww.rfc-editor.org/info/rfc7507>。
[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, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「輸送層セキュリティ（TLS）およびデータグラム輸送層セキュリティ（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487/RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, <https://www.rfc-editor.org/info/rfc7568>.
[RFC7568] Barnes、R.、Thomson、M.、Pironti、A。、およびA. Langley、「Secure Sockets Layerバージョン3.0」、RFC 7568、DOI 10.17487/RFC7568、2015年6月、<https：// ww。rfc-editor.org/info/rfc7568>。
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, <https://www.rfc-editor.org/info/rfc7590>.
[RFC7590] Saint-Andre、P。and T. Alkemade、「拡張可能なメッセージと存在プロトコル（XMPP）での輸送層セキュリティ（TLS）の使用」、RFC 7590、DOI 10.17487/RFC7590、2015年6月、<HTTPS：//www.rfc-editor.org/info/rfc7590>。
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) Feature Extension", RFC 7633, DOI 10.17487/RFC7633, October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7633] Hallam-Baker、P。、 "x.509v3輸送層セキュリティ（TLS）機能拡張"、RFC 7633、DOI 10.17487/RFC7633、2015年10月、<https://www.rfc-editor.org/info/RFC7633>。
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <https://www.rfc-editor.org/info/rfc7672>.
[RFC7672] Dukhovni、V。およびW. Hardaker、「名前付きエンティティ（DANE）輸送層セキュリティ（TLS）の日和見DNSベースの認証によるSMTPセキュリティ」、RFC 7672、DOI 10.17487/RFC7672、2015年10月、<HTTPS：//www.rfc-editor.org/info/rfc7672>。
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <https://www.rfc-editor.org/info/rfc7673>.
[RFC7673] Finch、T.、Miller、M。、およびP. Saint-Andre、「SRV Recordsを使用したDNSベースの認証（DANE）TLSAレコードを使用」、RFC 7673、DOI 10.17487/RFC7673、2015年10月、<https://www.rfc-editor.org/info/rfc7673>。
[RFC7712] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712, November 2015, <https://www.rfc-editor.org/info/rfc7712>.
[RFC7712] Saint-Andre、P.、Miller、M。、およびP. Hancke、「拡張可能なメッセージと存在プロトコル（XMPP）のドメイン名協会（DNA）」、RFC 7712、DOI 10.17487/RFC7712、2015年11月、<https://www.rfc-editor.org/info/rfc7712>。
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>.
[RFC7919] Gillmor、D。、「輸送層のセキュリティ（TLS）のための有限界面ディフェルマンの短命パラメーター」、RFC 7919、DOI 10.17487/RFC7919、2016年8月、<https://www.rfc-editor.org///情報/RFC7919>。
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/info/rfc7924>.
[RFC7924] Santesson、S。およびH. Tschofenig、「輸送層のセキュリティ（TLS）キャッシュ情報拡張」、RFC 7924、DOI 10.17487/RFC7924、2016年7月、<https：//www.rfc-editor.org/info/RFC7924>。
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/info/rfc7925>.
[RFC7925] Tschofenig、H.、ed。T. Fossati、「モノのインターネットの輸送層セキュリティ（TLS）/データグラムトランスポートレイヤーセキュリティ（DTLS）プロファイル」、RFC 7925、DOI 10.17487/RFC7925、2016年7月、<https：//www.rfc-editor。org/info/rfc7925>。
[RFC8452] Gueron, S., Langley, A., and Y. Lindell, "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", RFC 8452, DOI 10.17487/RFC8452, April 2019, <https://www.rfc-editor.org/info/rfc8452>.
[RFC8452] Gueron、S.、Langley、A。、およびY. Lindell、「AES-GCM-SIV：NONCE誤用耐性認証暗号化」、RFC 8452、DOI 10.17487/RFC8452、2019年4月、<https：// wwwwwwwwwwwwwwww.rfc-editor.org/info/rfc8452>。
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.
[RFC8461] Margolis、D.、Risher、M.、Ramakrishnan、B.、Brotman、A。、およびJ. Jones、「SMTP MTA Strict Transport Security（MTA-STS）」、RFC 8461、DOI 10.17487/RFC8461、9月2018、<https://www.rfc-editor.org/info/rfc8461>。
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.
[RFC8470] Thomson、M.、Nottingham、M.、およびW. Tarreau、「HTTPで初期データを使用」、RFC 8470、DOI 10.17487/RFC8470、2018年9月、<https://www.rfc-edtion.org/g/情報/RFC8470>。
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate Compression", RFC 8879, DOI 10.17487/RFC8879, December 2020, <https://www.rfc-editor.org/info/rfc8879>.
[RFC8879] Ghedini、A。and V. Vasiliev、「TLS証明書圧縮」、RFC 8879、DOI 10.17487/RFC8879、2020年12月、<https://www.rfc-editor.org/info/rfc8879>
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>.
[RFC9001] Thomson、M.、ed。and S. Turner、ed。、「TLSを使用してQUICを確保する」、RFC 9001、DOI 10.17487/RFC9001、2021年5月、<https://www.rfc-editor.org/info/rfc9001>。
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, <https://www.rfc-editor.org/info/rfc9051>.
[RFC9051] Melnikov、A.、ed。and B. Leiba、ed。、「インターネットメッセージアクセスプロトコル（IMAP） - バージョン4REV2」、RFC 9051、DOI 10.17487/RFC9051、2021年8月、<https://www.rfc-editor.org/info/rfc9051>。
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9110] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9112] Fielding、R.、Ed。、Ed。、Nottingham、M.、ed。、およびJ. Reschke、ed。、 "Http/1.1"、Std 99、RFC 9112、DOI 10.17487/RFC9112、2022年6月、<https：//www.rfc-editor.org/info/rfc9112>。
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[RFC9113] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/info/rfc9162>.
[RFC9162] Laurie、B.、Messeri、E。、およびR. Stradling、「証明書透明性バージョン2.0」、RFC 9162、DOI 10.17487/RFC9162、2021年12月、<https://www.rfc-editor.org/info/rfc9162>。
[RFC9191] Sethi, M., Preuß Mattsson, J., and S. Turner, "Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods", RFC 9191, DOI 10.17487/RFC9191, February 2022, <https://www.rfc-editor.org/info/rfc9191>.
[RFC9191] Sethi、M.、PreußMattsson、J。、およびS. Turner、「TLSベースのEAPメソッドでの大きな証明書と長い証明書チェーンの取り扱い」、RFC 9191、DOI 10.17487/RFC9191、2月2022年、<HTTPS：//www.rfc-editor.org/info/rfc9191>。
[SAFECURVES] Bernstein, D. J. and T. Lange, "SafeCurves: choosing safe curves for elliptic-curve cryptography", December 2014, <https://safecurves.cr.yp.to>.
[Safecurves] Bernstein、D。J。およびT. Lange、「Safecurves：erliptic-Curve Cryptographyの安全な曲線の選択」、2014年12月、<https://safecurves.cr.yp.to>。
[Soghoian2011] Soghoian, C. and S. Stamm, "Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL", SSRN Electronic Journal, DOI 10.2139/ssrn.1591033, April 2010, <https://doi.org/10.2139/ssrn.1591033>.
[Soghoian2011] Soghoian、C。and S. Stamm、「認定嘘：SSLに対する政府傍受攻撃の検出と敗北」、SSRN Electronic Journal、DOI 10.2139/SSRN.1591033、2010年4月、<https：//doi.org/10.21399999999999999999/SSRN.1591033>。
[Springall16] Springall, D., Durumeric, Z., and J. Halderman, "Measuring the Security Harm of TLS Crypto Shortcuts", Proceedings of the 2016 Internet Measurement Conference, pp. 33-47, DOI 10.1145/2987443.2987480, November 2016, <https://doi.org/10.1145/2987443.2987480>.
[Springall16] Springall、D.、Durumeric、Z.、およびJ. Halderman、「TLS Cryptoショートカットのセキュリティ害の測定」、2016年インターネット測定会議の議事録、pp。33-47、DOI 10.1145/2987443.2987480、2016年11月、<https://doi.org/10.1145/2987443.2987480>。
[STD53] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[STD53] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
<https://www.rfc-editor.org/info/std53>
[Sy2018] Sy, E., Burkert, C., Federrath, H., and M. Fischer, "Tracking Users across the Web via TLS Session Resumption", Proceedings of the 34th Annual Computer Security Applications Conference, pp. 289-299, DOI 10.1145/3274694.3274708, December 2018, <https://doi.org/10.1145/3274694.3274708>.
[SY2018] SY、E.、Burkert、C.、Federrath、H。、およびM. Fischer、「TLSセッション再開を介してWeb全体のユーザーを追跡する」、第34回年次コンピューターセキュリティアプリケーション会議の議事録、289-299、DOI 10.1145/3274694.3274708、2018年12月、<https://doi.org/10.1145/3274694.3274708>。
[TLS-ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-15, 3 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-15>.
[TLS-ECH] Rescorla、E.、Oku、K.、Sullivan、N。、およびC. A. Wood、「TLS暗号化クライアントHello」、Work in Progress、Internet-Draft、Draft-ITEF-TLS-ESNI-15、3 32022年10月、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-15>。
[Triple-Handshake] Bhargavan, K., Lavaud, A., Fournet, C., Pironti, A., and P. Strub, "Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS", 2014 IEEE Symposium on Security and Privacy, DOI 10.1109/sp.2014.14, May 2014, <https://doi.org/10.1109/sp.2014.14>.
[トリプルハンドシェイク] Bhargavan、K.、Lavaud、A.、Fournet、C.、Pironti、A.、およびP. Strub、「Triple Handshakes and Cookie Cutters：TLSを介した認証の破壊と修正」、2014 IEEE Symposium on Security on Securityプライバシー、DOI 10.1109/SP.2014.14、2014年5月、<https://doi.org/10.1109/sp.2014.14>。
[TWIRL] Shamir, A. and E. Tromer, "Factoring Large Numbers with the TWIRL Device", 2014 IEEE Symposium on Security and Privacy, DOI 10.1007/978-3-540-45146-4_1, 2004, <https://cs.tau.ac.il/~tromer/papers/twirl.pdf>.
[Twirl] Shamir、A。、およびE. Tromer、「Twirl Deviceで多数の大量を考慮」、2014 IEEE Symposium on Security and Privacy、DOI 10.1007/978-3-540-45146-4_1、2004、<https：//cs.tau.ac.il/~tromer/papers/twirl.pdf>。
This revision of the Best Current Practices contains numerous changes, and this section is focused on the normative changes.
最良の現在のプラクティスのこの改訂には多くの変更が含まれており、このセクションは規範的な変更に焦点を当てています。
* High-level differences:
* 高レベルの違い：
- Described the expectations from new TLS-incorporating transport protocols and from new application protocols layered on TLS.
- TLS上に階層化された新しいアプリケーションプロトコルからの新しいTLSを組み込むことからの期待を説明しました。
- Clarified items (e.g., renegotiation) that only apply to TLS 1.2.
- TLS 1.2にのみ適用される明確なアイテム（例：再交渉）。
- Changed the status of TLS 1.0 and 1.1 from "SHOULD NOT" to "MUST NOT".
- TLS 1.0と1.1のステータスを「ははずのはない」から「そうでない」に変更しました。
- Added TLS 1.3 at a "SHOULD" level.
- TLS 1.3を「必須」レベルで追加しました。
- Made similar changes to DTLS.
- DTLSに同様の変更を加えました。
- Included specific guidance for multiplexed protocols.
- 多重化プロトコルの特定のガイダンスが含まれています。
- MUST-level implementation requirement for ALPN and more specific SHOULD-level guidance for ALPN and SNI.
- ALPNの必須レベルの実装要件と、ALPNおよびSNIのより具体的なレベルのガイダンス。
- Clarified discussion of strict TLS policies, including MUST-level recommendations.
- 必見の推奨事項を含む、厳格なTLSポリシーの明確な議論。
- Limits on key usage.
- 主要な使用法の制限。
- New attacks since [RFC7457]: ALPACA, Raccoon, Logjam, and "Nonce-Disrespecting Adversaries".
- [RFC7457]以来の新しい攻撃：Alpaca、Raccoon、Logjam、および「非容疑者敵」。
- RFC 6961 (OCSP status_request_v2) has been deprecated.
- RFC 6961（OCSP Status_Request_v2）は非推奨です。
- MUST-level requirement for server-side RSA certificates to have a 2048-bit modulus at a minimum, replacing a "SHOULD".
- サーバー側のRSA証明書が2048ビットモジュラスを最低限に配置するための必須レベルの要件で、「必須」を置き換えます。
* Differences specific to TLS 1.2:
* TLS 1.2に固有の違い：
- SHOULD-level guidance on AES-GCM nonce generation.
- AES-GCM NonCe Generationに関するレベルのガイダンス。
- SHOULD NOT use (static or ephemeral) finite-field DH key agreement.
- （静的または一時的な）有限フィールドDHキー契約を使用しないでください。
- SHOULD NOT reuse ephemeral finite-field DH keys across multiple connections.
- 一時的な有限フィールドDHキーを複数の接続で再利用しないでください。
- SHOULD NOT use static Elliptic Curve DH key exchange.
- 静的楕円曲線DHキー交換を使用しないでください。
- 2048-bit DH is now a "MUST" and ECDH minimal curve size is 224 (vs. 192 previously).
- 2048ビットDHは「必須」であり、ECDH最小曲線サイズは224です（以前は192）。
- Support for extended_master_secret is now a "MUST" (previously it was a soft recommendation, as the RFC had not been published at the time). Also removed other, more complicated, related mitigations.
- extended_master_secretのサポートは現在「必須」です（以前はRFCが当時公開されていなかったため、これはソフトな推奨事項でした）。また、他の、より複雑な関連する緩和を削除しました。
- MUST-level restriction on session ticket validity, replacing a "SHOULD".
- セッションチケットの有効性の必見の制限は、「必須」を置き換えます。
- SHOULD-level restriction on the TLS session duration, depending on the rotation period of an [RFC5077] ticket key.
- [RFC5077]チケットキーの回転期間に応じて、TLSセッション期間のレベルの制限。
- Dropped TLS_DHE_RSA_WITH_AES from the recommended ciphers.
- 推奨される暗号からTLS_DHE_RSA_WITH_AESをドロップしました。
- Added TLS_ECDHE_ECDSA_WITH_AES to the recommended ciphers.
- 推奨される暗号にtls_ecdhe_ecdsa_with_aesを追加しました。
- SHOULD NOT use the old MTI cipher suite, TLS_RSA_WITH_AES_128_CBC_SHA.
- 古いMTI Cipherスイート、TLS_RSA_WITH_AES_128_CBC_SHAを使用しないでください。
- Recommended curve X25519 alongside NIST P-256.
- NIST P-256とともに、推奨曲線X25519。
* Differences specific to TLS 1.3:
* TLS 1.3に固有の違い：
- New TLS 1.3 capabilities: 0-RTT.
- 新しいTLS 1.3機能：0-RTT。
- Removed capabilities: renegotiation and compression.
- 削除された機能：再交渉と圧縮。
- Added mention of TLS Encrypted Client Hello, but no recommendation for use until it is finalized.
- TLS暗号化されたクライアントの言及を追加しましたが、完成するまで使用することを推奨しません。
- SHOULD-level requirement for forward secrecy in TLS 1.3 session resumption.
- TLS 1.3セッション再開における前方秘密のためのレベルの要件。
- Generic MUST-level guidance to avoid 0-RTT unless it is documented for the particular protocol.
- 特定のプロトコルに文書化されていない限り、0-RTTを回避するための一般的な必須レベルのガイダンス。
Acknowledgments
謝辞
Thanks to Alexey Melnikov, Alvaro Retana, Andrei Popov, Ben Kaduk, Christian Huitema, Corey Bonnell, Cullen Jennings, Daniel Kahn Gillmor, David Benjamin, Eric Rescorla, Éric Vyncke, Francesca Palombini, Hannes Tschofenig, Hubert Kario, Ilari Liusvaara, John Preuß Mattsson, John R. Levine, Julien Élie, Lars Eggert, Leif Johansson, Magnus Westerlund, Martin Duke, Martin Thomson, Mohit Sahni, Nick Sullivan, Nimrod Aviram, Paul Wouters, Peter Gutmann, Rich Salz, Robert Sayre, Robert Wilton, Roman Danyliw, Ryan Sleevi, Sean Turner, Stephen Farrell, Tim Evans, Valery Smyslov, Viktor Dukhovni, and Warren Kumari for helpful comments and discussions that have shaped this document.
Alexey Melnikov、Alvaro Retana、Andrei Popov、Ben Kaduk、Christian Huitema、Corey Bonnell、Cullen Jennings、Daniel Kahn Gillmor、David Benjamin、Eric Vyncke、Francesca Parombini、Hannes Tscofenig、Hunig、Hunig、Hannes tscofenig、hansca bebarisマッツソン、ジョン・R・レヴァイン、ジュリエン・エリー、ラース・エガート、レイフ・ヨハンソン、マグナス・ウェスターランド、マーティン・デューク、マーティン・トムソン、モヒト・サニ、ニック・サリバン、ニムロッド・アビラム、ポール・ウーターズ、ピーター・ガットマン、リッチ・サルツ、ロバート・セイアー、ロバート・ウィルトン、ローマンDanyliw、Ryan Sleevi、Sean Turner、Stephen Farrell、Tim Evans、Valery Smyslov、Viktor Dukhovni、Warren Kumariは、この文書を形作った有益なコメントと議論をしてくれました。
The authors gratefully acknowledge the contribution of Ralph Holz, who was a coauthor of RFC 7525, the previous version of the TLS recommendations.
著者は、TLSの推奨事項の以前のバージョンであるRFC 7525の共著者であったRalph Holzの貢献に感謝します。
See RFC 7525 for additional acknowledgments specific to the previous version of the TLS recommendations.
TLS推奨事項の以前のバージョンに固有の追加の謝辞については、RFC 7525を参照してください。
Authors' Addresses
著者のアドレス
Yaron Sheffer Intuit Email: yaronf.ietf@gmail.com
Yaron Sheffer Intuitメール：Yaronf.ietf@gmail.com
Peter Saint-Andre Independent Email: stpeter@stpeter.im
Peter Saint-Andre Independent Email：stpeter@stpeter.im
Thomas Fossati ARM Limited Email: thomas.fossati@arm.com
Thomas Fossati Arm Limited Email：thomas.fossati@arm.com