RFC 7919 - Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7919
タイトル : RFC 7919 - トランスポート層セキュリティ（TLS）の交渉済み有限体Diffie-Hellman一時パラメータ
翻訳編集 : 自動生成

[要約] RFC 7919は、Transport Layer Security (TLS) プロトコルにおける有限体Diffie-Hellman (DHE) 暗号のパラメータを交渉するための方法を定義しています。このRFCの目的は、TLS接続のセキュリティを強化するために、サーバーとクライアント間で安全にDHEパラメータを交換し、合意するメカニズムを提供することです。これにより、中間者攻撃に対する耐性を高め、通信の秘密性と完全性を保護します。RFC 7919は、TLS 1.2およびそれ以前のバージョンで使用され、後続のRFC 8446 (TLS 1.3) でさらに発展しています。関連するRFCにはRFC 5246 (TLS 1.2の定義) やRFC 8446 (TLS 1.3の定義) があります。

Internet Engineering Task Force (IETF)                        D. Gillmor
Request for Comments: 7919                                          ACLU
Updates: 2246, 4346, 4492, 5246                              August 2016
Category: Standards Track
ISSN: 2070-1721

Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)

トランスポート層セキュリティ（TLS）の交渉済み有限体Diffie-Hellman一時パラメータ

Abstract

概要

Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.

トランスポート層セキュリティ（TLS）ハンドシェイク中の従来の有限フィールドベースのDiffie-Hellman（DH）鍵交換は、多くのセキュリティ、相互運用性、および効率の欠点の影響を受けます。これらの欠点は、TLSサーバーが提供し、クライアントが受け入れる必要のあるDHグループパラメーターが明確でないことから生じます。このドキュメントは、TLSの「サポートされているグループレジストリ」（このドキュメントでは「EC Named Curve Registry」から改名）のセクションを使用して、既知の構造とメカニズムを持つ共通の有限フィールドDHパラメータを確立することにより、互換性のあるピアのこれらの欠点の解決策を提供します。これらのグループのサポートについて交渉する仲間。

This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).

このドキュメントは、TLSバージョン1.0（RFC 2246）、1.1（RFC 4346）、および1.2（RFC 5246）、ならびにTLS Elliptic Curve Cryptography（ECC）拡張（RFC 4492）を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7919.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7919で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     1.2.  Vocabulary  . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Named Group Overview  . . . . . . . . . . . . . . . . . . . .   5
   3.  Client Behavior . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Client Local Policy on Custom Groups  . . . . . . . . . .   7
   4.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Optimizations . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Checking the Peer's Public Key  . . . . . . . . . . . . .   9
     5.2.  Short Exponents . . . . . . . . . . . . . . . . . . . . .   9
     5.3.  Table Acceleration  . . . . . . . . . . . . . . . . . . .  10
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  10
     6.1.  Preference Ordering . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.1.  Negotiation Resistance to Active Attacks  . . . . . . . .  12
     8.2.  Group Strength Considerations . . . . . . . . . . . . . .  13
     8.3.  Finite Field DHE Only . . . . . . . . . . . . . . . . . .  13
     8.4.  Deprecating Weak Groups . . . . . . . . . . . . . . . . .  14
     8.5.  Choice of Groups  . . . . . . . . . . . . . . . . . . . .  14
     8.6.  Timing Attacks  . . . . . . . . . . . . . . . . . . . . .  14
     8.7.  Replay Attacks from Non-negotiated FFDHE  . . . . . . . .  15
     8.8.  Forward Secrecy . . . . . . . . . . . . . . . . . . . . .  15
     8.9.  False Start . . . . . . . . . . . . . . . . . . . . . . .  15
   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16
     9.1.  Client Fingerprinting . . . . . . . . . . . . . . . . . .  16
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Supported Groups Registry (Formerly "EC Named Curve
                Registry") . . . . . . . . . . . . . . . . . . . . .  19
     A.1.  ffdhe2048 . . . . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  ffdhe3072 . . . . . . . . . . . . . . . . . . . . . . . .  20
     A.3.  ffdhe4096 . . . . . . . . . . . . . . . . . . . . . . . .  22
     A.4.  ffdhe6144 . . . . . . . . . . . . . . . . . . . . . . . .  23
     A.5.  ffdhe8192 . . . . . . . . . . . . . . . . . . . . . . . .  26
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  29
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

1. Introduction

1. はじめに

Traditional TLS [RFC5246] offers a Diffie-Hellman Ephemeral (DHE) key exchange mode that provides forward secrecy for the connection. The client offers a cipher suite in the ClientHello that includes DHE, and the server offers the client group parameters generator g and modulus p. If the client does not consider the group strong enough (e.g., p is too small, p is not prime, or there are small subgroups that cannot be easily avoided) or if it is unable to process the group for other reasons, the client has no recourse but to terminate the connection.

従来のTLS [RFC5246]は、接続に転送秘密を提供するDiffie-Hellman Ephemeral（DHE）鍵交換モードを提供します。クライアントはDHEを含むClientHelloで暗号スイートを提供し、サーバーはクライアントグループパラメータージェネレーターgおよびモジュラスpを提供します。クライアントがグループを十分に強いと見なさない場合（たとえば、pが小さすぎる、pが素数でない、または簡単に回避できない小さなサブグループがある）、または他の理由でグループを処理できない場合、クライアントは接続を終了する以外の手段はありません。

Conversely, when a TLS server receives a suggestion for a DHE cipher suite from a client, it has no way of knowing what kinds of DH groups the client is capable of handling or what the client's security requirements are for this key exchange session. For example, some widely distributed TLS clients are not capable of DH groups where p > 1024 bits. Other TLS clients may, by policy, wish to use DHE only if the server can offer a stronger group (and are willing to use a non-PFS (Perfect Forward Secrecy) key exchange mechanism otherwise). The server has no way of knowing which type of client is connecting but must select DH parameters with insufficient knowledge.

逆に、TLSサーバーがクライアントからDHE暗号スイートの提案を受け取った場合、クライアントが処理できるDHグループの種類や、この鍵交換セッションに対するクライアントのセキュリティ要件を知る方法はありません。たとえば、広く分散されている一部のTLSクライアントは、p> 1024ビットのDHグループに対応していません。他のTLSクライアントは、ポリシーにより、サーバーがより強力なグループを提供できる場合にのみDHEを使用することを希望する場合があります（それ以外の場合は、非PFS（Perfect Forward Secrecy）の鍵交換メカニズムを使用してもかまいません）。サーバーは接続しているクライアントのタイプを知る方法がありませんが、知識が不十分なDHパラメーターを選択する必要があります。

Additionally, the DH parameters selected by the server may have a known structure that renders them secure against a small subgroup attack, but a client receiving an arbitrary p and g has no efficient way to verify that the structure of a new group is reasonable for use.

さらに、サーバーによって選択されたDHパラメーターは、小さなサブグループ攻撃に対してそれらを安全にする既知の構造を持っているかもしれませんが、任意のpおよびgを受信するクライアントは、新しいグループの構造が使用に妥当であることを確認する効率的な方法がありません。

This modification to TLS solves these problems by using a section of the "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to select common DH groups with known structure and defining the use of the "elliptic_curves(10)" extension (described here as the Supported Groups extension) for clients advertising support for DHE with these groups. This document also provides guidance for compatible peers to take advantage of the additional security, availability, and efficiency offered.

このTLSへの変更は、「サポートされるグループレジストリ」のセクション（このドキュメントでは「EC Named Curve Registry」から改名）を使用して既知の構造を持つ一般的なDHグループを選択し、「elliptic_curves（10）の使用を定義することで、これらの問題を解決します。 "これらのグループを使用してDHEのサポートをアドバタイズするクライアント用の拡張機能（ここでは、サポートされるグループの拡張機能として説明）。このドキュメントでは、互換性のあるピアが提供する追加のセキュリティ、可用性、および効率を利用するためのガイダンスも提供します。

The use of this mechanism by one compatible peer when interacting with a non-compatible peer should have no detrimental effects.

互換性のないピアと対話するときに、1つの互換性のあるピアがこのメカニズムを使用しても、悪影響はありません。

This document updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246], as well as the TLS ECC extensions [RFC4492].

このドキュメントは、TLSバージョン1.0 [RFC2246]、1.1 [RFC4346]、および1.2 [RFC5246]、およびTLS ECC拡張[RFC4492]を更新します。

1.1. Requirements Language

1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

1.2. Vocabulary

1.2. 単語

The terms "DHE" or "FFDHE" are used in this document to refer to the finite-field-based Diffie-Hellman ephemeral key exchange mechanism in TLS. TLS also supports Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchanges [RFC4492], but this document does not document their use. A registry previously used only by ECDHE-capable implementations is expanded in this document to cover FFDHE groups as well. "FFDHE cipher suites" is used in this document to refer exclusively to cipher suites with FFDHE key exchange mechanisms, but note that these suites are typically labeled with a TLS_DHE_ prefix.

このドキュメントでは、「DHE」または「FFDHE」という用語を使用して、TLSの有限フィールドベースのDiffie-Hellman一時鍵交換メカニズムを指します。 TLSはまた、Elliptic Curve Diffie-Hellman Ephemeral（ECDHE）鍵交換[RFC4492]もサポートしますが、このドキュメントではそれらの使用については説明していません。以前にECDHE対応の実装でのみ使用されていたレジストリは、このドキュメントではFFDHEグループもカバーするように拡張されています。このドキュメントでは、「FFDHE暗号スイート」を使用して、FFDHE鍵交換メカニズムを備えた暗号スイートのみを指しますが、これらのスイートには、通常、TLS_DHE_プレフィックスが付いています。

2. Named Group Overview

2. 名前付きグループの概要

We use previously unallocated codepoints within the extension currently known as "elliptic_curves" (Section 5.1.1. of [RFC4492]) to indicate known finite field groups. The extension's semantics are expanded from "Supported Elliptic Curves" to "Supported Groups". The enum datatype used in the extension has been renamed from NamedCurve to NamedGroup. Its semantics are likewise expanded from "named curve" to "named group".

現在「elliptic_curves」（[RFC4492]のセクション5.1.1。）として知られている拡張機能内の未割り当てのコードポイントを使用して、既知の有限体グループを示します。拡張機能のセマンティクスは、「サポートされる楕円曲線」から「サポートされるグループ」に拡張されました。拡張機能で使用される列挙型データ型は、NamedCurveからNamedGroupに名前が変更されました。そのセマンティクスも同様に「名前付き曲線」から「名前付きグループ」に拡張されています。

Additionally, we explicitly relax the requirement about when the Supported Groups extension can be sent. This extension MAY be sent by the client when either FFDHE or ECDHE cipher suites are listed.

さらに、サポートされているグループ拡張をいつ送信できるかについての要件を明示的に緩和します。この拡張は、FFDHEまたはECDHE暗号スイートのいずれかがリストされている場合にクライアントによって送信される場合があります。

Codepoints in the "Supported Groups Registry" with a high byte of 0x01 (that is, between 256 and 511, inclusive) are set aside for FFDHE groups, though only a small number of them are initially defined and we do not expect many other FFDHE groups to be added to this range. No codepoints outside of this range will be allocated to FFDHE groups. The new codepoints for the "Supported Groups Registry" are:

0x01の上位バイト（つまり、256から511まで）を含む「サポートされるグループレジストリ」のコードポイントは、FFDHEグループ用に確保されていますが、最初に定義されるのは少数であり、他の多くのFFDHEは想定されていませんこの範囲に追加するグループ。この範囲外のコードポイントはFFDHEグループに割り当てられません。「サポートされているグループレジストリ」の新しいコードポイントは次のとおりです。

           enum {
           // other already defined elliptic curves (see RFC 4492)
               ffdhe2048(256), ffdhe3072(257), ffdhe4096(258),
               ffdhe6144(259), ffdhe8192(260),
           //
           } NamedGroup;

These additions to the "Supported Groups Registry" are described in detail in Appendix A. They are all safe primes derived from the base of the natural logarithm ("e"), with the high and low 64 bits set to 1 for efficient Montgomery or Barrett reduction.

「サポートされるグループレジストリ」へのこれらの追加については、付録Aで詳細に説明します。これらはすべて、自然対数（「e」）の底から派生した安全な素数であり、高および低64ビットが1に設定されて、効率的なモンゴメリーまたはバレット削減。

The use of the base of the natural logarithm here is as a "nothing-up-my-sleeve" number. The goal is to guarantee that the bits in the middle of the modulus are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak according to some secret criteria. [RFC3526] used pi for this value. See Section 8.5 for reasons that this document does not reuse pi.

ここでの自然対数の底の使用は、「何もしていません」という数値として使用されます。目標は、素数が秘密の基準に従って弱く選択されているという疑いを回避しながら、係数の中央のビットが事実上ランダムであることを保証することです。 [RFC3526]はこの値にpiを使用しました。このドキュメントがpiを再利用しない理由については、セクション8.5を参照してください。

3. Client Behavior

3. クライアントの動作

A TLS client that is capable of using strong finite field Diffie-Hellman groups can advertise its capabilities and its preferences for stronger key exchange by using this mechanism.

強力な有限フィールドのDiffie-Hellmanグループを使用できるTLSクライアントは、このメカニズムを使用して、その機能と、より強力な鍵交換のための設定を通知できます。

The compatible client that wants to be able to negotiate strong FFDHE sends a Supported Groups extension (identified by type elliptic_curves(10) in [RFC4492]) in the ClientHello and includes a list of known FFDHE groups in the extension data, ordered from most preferred to least preferred. If the client also supports and wants to offer ECDHE key exchange, it MUST use a single Supported Groups extension to include all supported groups (both ECDHE and FFDHE groups). The ordering SHOULD be based on client preference, but see Section 6.1 for more nuance.

強力なFFDHEをネゴシエートできるようにしたい互換性のあるクライアントは、ClientHelloでサポートグループ拡張（[RFC4492]のタイプelliptic_curves（10）で識別）を送信し、拡張データに既知のFFDHEグループのリストを含めます。あまり好ましくない。クライアントがECDHEキー交換もサポートし、提供したい場合は、サポートされているすべてのグループ（ECDHEグループとFFDHEグループの両方）を含めるために、単一のサポートグループ拡張を使用する必要があります。順序はクライアントの設定に基づく必要があります（SHOULD）が、詳細についてはセクション6.1を参照してください。

A client that offers a Supported Groups extension containing an FFDHE group SHOULD also include at least one FFDHE cipher suite in the ClientHello.

FFDHEグループを含むサポートグループ拡張を提供するクライアントは、ClientHelloに少なくとも1つのFFDHE暗号スイートも含める必要があります（SHOULD）。

A client that offers a group MUST be able and willing to perform a DH key exchange using that group.

グループを提供するクライアントは、そのグループを使用してDH鍵交換を実行する能力があり、喜んで実行する必要があります。

A client that offers one or more FFDHE groups in the Supported Groups extension and an FFDHE cipher suite and that receives an FFDHE cipher suite from the server SHOULD take the following steps upon receiving the ServerKeyExchange:

サポートグループ拡張の1つ以上のFFDHEグループとFFDHE暗号スイートを提供し、サーバーからFFDHE暗号スイートを受信するクライアントは、ServerKeyExchangeの受信時に次の手順を実行する必要があります（SHOULD）。

o For non-anonymous cipher suites where the offered certificate is valid and appropriate for the peer, validate the signature over the ServerDHParams. If not valid, terminate the connection.

o 提供された証明書が有効でピアに適した非匿名の暗号スイートの場合は、ServerDHParamsで署名を検証します。有効でない場合は、接続を終了します。

o If the signature over ServerDHParams is valid, compare the selected dh_p and dh_g with the FFDHE groups offered by the client. If none of the offered groups match, the server is not compatible with this document. The client MAY decide to continue the connection if the selected group is acceptable under local policy, or it MAY decide to terminate the connection with a fatal insufficient_security(71) alert.

o ServerDHParamsを介した署名が有効な場合は、選択したdh_pおよびdh_gを、クライアントが提供するFFDHEグループと比較します。提供されたグループのいずれも一致しない場合、サーバーはこのドキュメントと互換性がありません。クライアントは、選択されたグループがローカルポリシーで受け入れ可能である場合、接続を継続することを決定する場合があります。

o If the client continues (either because the server offered a matching group or because local policy permits the offered custom group), the client MUST verify that dh_Ys is in the range 1 < dh_Ys < dh_p - 1. If dh_Ys is not in this range, the client MUST terminate the connection with a fatal handshake_failure(40) alert.

o クライアントが続行する場合（サーバーが一致するグループを提供したため、またはローカルポリシーが提供されたカスタムグループを許可するため）、クライアントはdh_Ysが1 <dh_Ys <dh_p-1の範囲にあることを確認する必要があります。dh_Ysがこの範囲にない場合、クライアントは致命的なhandshake_failure（40）アラートで接続を終了しなければなりません（MUST）。

o If dh_Ys is in range, then the client SHOULD continue with the connection as usual.

o dh_Ysが範囲内にある場合、クライアントは通常どおり接続を続行する必要があります（SHOULD）。

3.1. Client Local Policy on Custom Groups

3.1. カスタムグループのクライアントローカルポリシー

Compatible clients that are willing to accept FFDHE cipher suites from non-compatible servers may have local policy about what custom FFDHE groups they are willing to accept. This local policy presents a risk to clients, who may accept weakly protected communications from misconfigured servers.

互換性のないサーバーからのFFDHE暗号スイートを受け入れようとする互換性のあるクライアントは、受け入れるカスタムFFDHEグループについてローカルポリシーを持っている可能性があります。このローカルポリシーは、クライアントにリスクをもたらします。クライアントは、誤って構成されたサーバーからの弱く保護された通信を受け入れる可能性があります。

This document cannot enumerate all possible safe local policy (the safest may be to simply reject all custom groups), but compatible clients that accept some custom groups from the server MUST do at least cursory checks on group size and may take other properties into consideration as well.

このドキュメントでは、可能なすべての安全なローカルポリシーを列挙することはできません（最も安全なのは、すべてのカスタムグループを拒否することです）。ただし、サーバーからいくつかのカスタムグループを受け入れる互換性のあるクライアントは、少なくともグループサイズを大まかにチェックし、他のプロパティを考慮に入れる必要があります。上手。

A compatible client that accepts FFDHE cipher suites using custom groups from non-compatible servers MUST reject any group with |dh_p| < 768 bits and SHOULD reject any group with |dh_p| < 1024 bits.

互換性のないサーバーからのカスタムグループを使用してFFDHE暗号スイートを受け入れる互換性のあるクライアントは、| dh_p |でグループを拒否する必要があります。 768ビット未満であり、| dh_p |でグループを拒否する必要があります（SHOULD）。 1024ビット未満。

A compatible client that rejects a non-compatible server's custom group may decide to retry the connection while omitting all FFDHE cipher suites from the ClientHello. A client SHOULD only use this approach if it successfully verified the server's expected signature over the ServerDHParams, to avoid being forced by an active attacker into a non-preferred cipher suite.

非互換サーバーのカスタムグループを拒否する互換クライアントは、ClientHelloからすべてのFFDHE暗号スイートを省略しながら、接続を再試行する場合があります。クライアントは、ServerDHParamsを介してサーバーの予想される署名を正常に検証した場合にのみ、このアプローチを使用して、アクティブな攻撃者による非推奨の暗号スイートへの強制を回避する必要があります。

4. Server Behavior

4. サーバーの動作

If a compatible TLS server receives a Supported Groups extension from a client that includes any FFDHE group (i.e., any codepoint between 256 and 511, inclusive, even if unknown to the server), and if none of the client-proposed FFDHE groups are known and acceptable to the server, then the server MUST NOT select an FFDHE cipher suite. In this case, the server SHOULD select an acceptable non-FFDHE cipher suite from the client's offered list. If the extension is present with FFDHE groups, none of the client's offered groups are acceptable by the server, and none of the client's proposed non-FFDHE cipher suites are acceptable to the server, the server MUST end the connection with a fatal TLS alert of type insufficient_security(71).

互換性のあるTLSサーバーが、FFDHEグループ（サーバーに認識されていない場合でも、256から511までのコードポイントを含む）を含むサポートグループ拡張をクライアントから受信し、クライアントが提案するFFDHEグループがどれも既知でない場合サーバーに受け入れられる場合、サーバーはFFDHE暗号スイートを選択してはなりません（MUST NOT）。この場合、サーバーは、クライアントの提供リストから、受け入れ可能な非FFDHE暗号スイートを選択する必要があります（SHOULD）。拡張がFFDHEグループに存在する場合、クライアントが提供するグループはサーバーで受け入れられず、クライアントが提案する非FFDHE暗号スイートもサーバーで受け入れられない場合、サーバーは、致命的なTLSアラートで接続を終了する必要があります。不十分なタイプのセキュリティ（71）。

If at least one FFDHE cipher suite is present in the client cipher suite list and the Supported Groups extension is either absent from the ClientHello entirely or contains no FFDHE groups (i.e., no codepoints between 256 and 511, inclusive), then the server knows that the client is not compatible with this document. In this scenario, a server MAY select a non-FFDHE cipher suite, or it MAY select an FFDHE cipher suite and offer an FFDHE group of its choice to the client as part of a traditional ServerKeyExchange.

少なくとも1つのFFDHE暗号スイートがクライアント暗号スイートリストに存在し、サポートグループ拡張がClientHelloに完全に存在しないか、FFDHEグループを含まない（つまり、256から511までのコードポイントがない）場合、サーバーはそれを認識します。クライアントはこのドキュメントと互換性がありません。このシナリオでは、サーバーは非FFDHE暗号スイートを選択するか、またはFFDHE暗号スイートを選択して、従来のServerKeyExchangeの一部として選択したFFDHEグループをクライアントに提供する場合があります。

A compatible TLS server that receives the Supported Groups extension with FFDHE codepoints in it and that selects an FFDHE cipher suite MUST select one of the client's offered groups. The server indicates the choice of group to the client by sending the group's parameters as usual in the ServerKeyExchange as described in Section 7.4.3 of [RFC5246].

FFDHEコードポイントを含むサポートグループ拡張を受信し、FFDHE暗号スイートを選択する互換性のあるTLSサーバーは、クライアントが提供するグループの1つを選択する必要があります。 [RFC5246]のセクション7.4.3で説明されているように、サーバーはServerKeyExchangeで通常どおりグループのパラメータを送信することにより、クライアントにグループの選択を示します。

A TLS server MUST NOT select a named FFDHE group that was not offered by a compatible client.

TLSサーバーは、互換性のあるクライアントによって提供されなかった名前付きFFDHEグループを選択してはなりません（MUST NOT）。

A TLS server MUST NOT select an FFDHE cipher suite if the client did not offer one, even if the client offered an FFDHE group in the Supported Groups extension.

クライアントがサポートされているグループ拡張でFFDHEグループを提供した場合でも、クライアントが提供していない場合、TLSサーバーはFFDHE暗号スイートを選択してはなりません（MUST NOT）。

If a non-anonymous FFDHE cipher suite is selected and the TLS client has used this extension to offer an FFDHE group of comparable or greater strength than the server's public key, the server SHOULD select an FFDHE group at least as strong as the server's public key. For example, if the server has a 3072-bit RSA key and the client offers only ffdhe2048 and ffdhe4096, the server SHOULD select ffdhe4096.

非匿名のFFDHE暗号スイートが選択され、TLSクライアントがこの拡張機能を使用して、サーバーの公開鍵と同等またはそれ以上の強度のFFDHEグループを提供している場合、サーバーは少なくともサーバーの公開鍵と同じくらい強いFFDHEグループを選択する必要があります（SHOULD）。たとえば、サーバーに3072ビットのRSAキーがあり、クライアントがffdhe2048とffdhe4096のみを提供している場合、サーバーはffdhe4096を選択する必要があります（SHOULD）。

When an FFDHE cipher suite is selected and the client sends a ClientKeyExchange, the server MUST verify that 1 < dh_Yc < dh_p - 1. If dh_Yc is out of range, the server MUST terminate the connection with a fatal handshake_failure(40) alert.

FFDHE暗号スイートが選択され、クライアントがClientKeyExchangeを送信する場合、サーバーは1 <dh_Yc <dh_p-1であることを確認する必要があります。dh_Ycが範囲外の場合、サーバーは致命的なhandshake_failure（40）アラートで接続を終了する必要があります。

5. Optimizations

5. 最適化

In a key exchange with a successfully negotiated known FFDHE group, both peers know that the group in question uses a safe prime as a modulus and that the group in use is of size p-1 or (p-1)/2. This allows at least three optimizations that can be used to improve performance.

正常にネゴシエートされた既知のFFDHEグループとの鍵交換では、両方のピアは、問題のグループが係数として安全な素数を使用し、使用中のグループのサイズがp-1または（p-1）/ 2であることを知っています。これにより、パフォーマンスを改善するために使用できる少なくとも3つの最適化が可能になります。

5.1. Checking the Peer's Public Key

5.1. ピアの公開鍵の確認

Peers MUST validate each other's public key Y (dh_Ys offered by the server or dh_Yc offered by the client) by ensuring that 1 < Y < p-1. This simple check ensures that the remote peer is properly behaved and isn't forcing the local system into the 2-element subgroup.

ピアは、1 <Y <p-1であることを確認することにより、互いの公開鍵Y（サーバーによって提供されるdh_Ysまたはクライアントによって提供されるdh_Yc）を検証する必要があります。この単純なチェックにより、リモートピアが適切に動作し、ローカルシステムが2要素のサブグループに強制されないことが保証されます。

To reach the same assurance with an unknown group, the client would need to verify the primality of the modulus, learn the factors of p-1, and test both the generator g and Y against each factor to avoid small subgroup attacks.

未知のグループで同じ保証を得るには、クライアントは係数の素数を検証し、p-1の係数を学習し、小さなサブグループ攻撃を回避するために各係数に対してジェネレーターgとYの両方をテストする必要があります。

5.2. Short Exponents

5.2. 短い指数

Traditional finite field Diffie-Hellman has each peer choose their secret exponent from the range [2, p-2]. Using exponentiation by squaring, this means each peer must do roughly 2*log_2(p) multiplications, twice (once for the generator and once for the peer's public key).

従来の有限体Diffie-Hellmanでは、各ピアに秘密の指数を[2、p-2]の範囲から選択させます。二乗による指数を使用すると、これは、各ピアが約2 * log_2（p）の乗算を2回（ジェネレータに対して1回、ピアの公開鍵に対して1回）行う必要があることを意味します。

Peers concerned with performance may also prefer to choose their secret exponent from a smaller range, doing fewer multiplications, while retaining the same level of overall security. Each named group indicates its approximate security level and provides a lower bound on the range of secret exponents that should preserve it. For example, rather than doing 2*2*3072 multiplications for an ffdhe3072 handshake, each peer can choose to do 2*2*275 multiplications by choosing their secret exponent from the range [2^274, 2^275] (that is, an m-bit integer where m is at least 275) and still keep the same approximate security level.

パフォーマンスに関心のあるピアは、同じレベルの全体的なセキュリティを維持しながら、小さい範囲から秘密の指数を選択し、乗算を少なくすることを好む場合もあります。それぞれの名前付きグループは、おおよそのセキュリティレベルを示し、それを保持する秘密指数の範囲の下限を提供します。たとえば、各ピアは、ffdhe3072ハンドシェイクに対して2 * 2 * 3072乗算を行うのではなく、[2 ^ 274、2 ^ 275]の範囲から秘密指数を選択することで、2 * 2 * 275乗算を実行することを選択できます（つまり、 mビット整数（mは少なくとも275）であり、おおよそのセキュリティレベルを維持します。

A similar short-exponent approach is suggested in a Secure SHell (SSH) Diffie-Hellman key exchange (see Section 6.2 of [RFC4419]).

Secure SHell（SSH）Diffie-Hellman鍵交換では、同様の短指数アプローチが推奨されています（[RFC4419]のセクション6.2を参照）。

5.3. Table Acceleration

5.3. テーブルアクセラレーション

Peers wishing to further accelerate FFDHE key exchange can also pre-compute a table of powers of the generator of a known group. This is a memory vs. time trade-off, and it only accelerates the first exponentiation of the ephemeral DH exchange (the fixed-base exponentiation). The variable-base exponentiation (using the peer's public exponent as a base) still needs to be calculated as normal.

FFDHEキー交換をさらに加速したいピアは、既知のグループのジェネレータのパワーのテーブルを事前に計算することもできます。これはメモリと時間のトレードオフであり、一時的なDH交換の最初の累乗（固定ベースの累乗）を加速するだけです。変数ベースの指数（ピアの公開指数をベースとして使用）は、通常どおり計算する必要があります。

6. Operational Considerations

6. 運用上の考慮事項

6.1. Preference Ordering

6.1. 優先順位

The ordering of named groups in the Supported Groups extension may contain some ECDHE groups and some FFDHE groups. These SHOULD be ranked in the order preferred by the client.

サポートされているグループ拡張機能での名前付きグループの順序には、一部のECDHEグループと一部のFFDHEグループが含まれる場合があります。これらは、クライアントが優先する順序でランク付けする必要があります。

However, the ClientHello also contains a list of desired cipher suites, also ranked in preference order. This presents the possibility of conflicted preferences. For example, if the ClientHello contains a cipher_suite field with two choices in order <TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA> and the Supported Groups extension contains two choices in order <secp256r1,ffdhe3072>, then there is a clear contradiction. Clients SHOULD NOT present such a contradiction since it does not represent a sensible ordering. A server that encounters such a contradiction when selecting between an ECDHE or FFDHE key exchange mechanism while trying to respect client preferences SHOULD give priority to the Supported Groups extension (in the example case, it should select TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp256r1) but MAY resolve the contradiction any way it sees fit.

ただし、ClientHelloには、希望する暗号スイートのリストも含まれており、これらも優先順位でランク付けされています。これは、相反する設定の可能性を示しています。たとえば、ClientHelloに<TLS_DHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA>の順序で2つの選択肢があるcipher_suiteフィールドが含まれ、Supported Groups拡張機能に<secp256r1、ffdhe3072>の順序で2つの選択肢が含まれている場合、矛盾が生じます。それは賢明な順序付けを表していないので、クライアントはそのような矛盾を示すべきではありません。 ECDHEまたはFFDHEのどちらかのキー交換メカニズムを選択するときにクライアント設定を尊重しようとするときにこのような矛盾に遭遇したサーバーは、サポートグループ拡張を優先する必要があります（この場合、この例では、secp256r1でTLS_ECDHE_RSA_WITH_AES_128_CBC_SHAを選択する必要があります）。それが合うように見える方法。

More subtly, clients MAY interleave preferences between ECDHE and FFDHE groups; for example, if stronger groups are preferred regardless of cost, but weaker groups are acceptable, the Supported Groups extension could consist of <ffdhe8192,secp384p1,ffdhe3072,secp256r1>. In this example, with the same cipher_suite field offered as the previous example, a server configured to respect client preferences and with support for all listed groups SHOULD select TLS_DHE_RSA_WITH_AES_128_CBC_SHA with ffdhe8192. A server configured to respect client preferences and with support for only secp384p1 and ffdhe3072 SHOULD select TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA with secp384p1.

より微妙に、クライアントはECDHEグループとFFDHEグループの間で設定をインターリーブしてもよい（MAY）。たとえば、コストに関係なく強いグループが優先され、弱いグループは許容できる場合、サポートされるグループの拡張機能は<ffdhe8192、secp384p1、ffdhe3072、secp256r1>で構成できます。この例では、前の例と同じcipher_suiteフィールドを使用して、サーバーはクライアント設定を尊重するように構成され、リストされたすべてのグループをサポートして、ffdhe8192でTLS_DHE_RSA_WITH_AES_128_CBC_SHAを選択する必要があります。クライアント設定を尊重するように構成され、secp384p1とffdhe3072のみをサポートするサーバーは、secp384p1でTLS_ECDHE_RSA_WITH_AES_128_CBC_SHAを選択する必要があります（SHOULD）。

7. IANA Considerations

7. IANAに関する考慮事項

This document renames the "EC Named Curve Registry" (originally defined in [RFC4492] and updated by [RFC7027]) to the "Supported Groups Registry". See <https://www.iana.org/assignments/tls-parameters>.

このドキュメントでは、「EC Named Curve Registry」（[RFC4492]で最初に定義され、[RFC7027]によって更新された）の名前を「Supported Groups Registry」に変更します。 <https://www.iana.org/assignments/tls-parameters>を参照してください。

This document expands the semantics of this registry to include groups based on finite fields in addition to groups based on elliptic curves. IANA has added a range designation to the registry, indicating that values from 256-511 (inclusive) are set aside for "Finite Field Diffie-Hellman groups" and that all other entries in the registry are "Elliptic curve groups".

このドキュメントでは、このレジストリのセマンティクスを拡張して、楕円曲線に基づくグループに加えて、有限体に基づくグループを含めます。 IANAはレジストリに範囲指定を追加しました。これは、「Finite Field Diffie-Hellman groups」には256〜511（両端を含む）の値が設定され、レジストリ内の他のすべてのエントリは「Elliptic curve groups」であることを示しています。

This document allocates five well-defined codepoints in the registry for specific finite field Diffie-Hellman groups defined in Appendix A.

このドキュメントでは、付録Aで定義されている特定の有限体Diffie-Hellmanグループのレジストリに5つの明確に定義されたコードポイントを割り当てます。

In addition, the four highest codepoints in the range 508-511, inclusive, are designated for Private Use [RFC5226] by peers who have privately developed finite field Diffie-Hellman groups that they wish to signal internally.

さらに、508〜511の範囲の4つの最高コードポイントは、内部で信号を送りたい有限フィールドDiffie-Hellmanグループを私的に開発したピアによって、プライベート使用[RFC5226]に指定されています。

The updated registry section is as follows:

更新されたレジストリセクションは次のとおりです。

   +---------+-------------+---------+-----------+
   | Value   | Description | DTLS-OK | Reference |
   +---------+-------------+---------+-----------+
   | 256     | ffdhe2048   | Y       | RFC 7919  |
   | 257     | ffdhe3072   | Y       | RFC 7919  |
   | 258     | ffdhe4096   | Y       | RFC 7919  |
   | 259     | ffdhe6144   | Y       | RFC 7919  |
   | 260     | ffdhe8192   | Y       | RFC 7919  |
   | 508-511 | Private Use | -       | RFC 7919  |
   +---------+-------------+---------+-----------+

IANA has also renamed the "elliptic_curves" extension as "supported_groups" and added a reference to this document in the "ExtensionType Values" registry. See <http://www.iana.org/assignments/tls-extensiontype-values>.

IANAは、「elliptic_curves」拡張の名前を「supported_groups」に変更し、このドキュメントへの参照を「ExtensionType値」レジストリに追加しました。 <http://www.iana.org/assignments/tls-extensiontype-values>を参照してください。

8. Security Considerations

8. セキュリティに関する考慮事項

8.1. Negotiation Resistance to Active Attacks

8.1. アクティブな攻撃に対する交渉の抵抗

Because the contents of the Supported Groups extension are hashed in the Finished message, an active Man in the Middle (MITM) that tries to filter or omit groups will cause the handshake to fail, but possibly not before getting the peer to do something it would not otherwise have done.

サポートされているグループ拡張の内容は終了メッセージでハッシュされるため、グループをフィルタリングまたは除外しようとするアクティブな中間者（MITM）が原因でハンドシェイクが失敗しますが、ピアに何かをさせる前に失敗する可能性がありますそうでなければしていません。

An attacker who impersonates the server can try to do any of the following:

サーバーを偽装した攻撃者は、次のことを試みることができます。

o Pretend that a non-compatible server is actually capable of this extension and select a group from the client's list, causing the client to select a group it is willing to negotiate. It is unclear how this would be an effective attack.

o 互換性のないサーバーが実際にこの拡張機能を備えていると想定して、クライアントのリストからグループを選択し、クライアントが交渉したいグループを選択するようにします。これがどのように効果的な攻撃になるかは不明です。

o Pretend that a compatible server is actually non-compatible by negotiating a non-FFDHE cipher suite. This is no different than MITM cipher suite filtering.

o 非FFDHE暗号スイートをネゴシエートすることにより、互換性のあるサーバーが実際には非互換であるふりをします。これはMITM暗号スイートのフィルタリングと同じです。

o Pretend that a compatible server is actually non-compatible by negotiating a DHE cipher suite with a custom (perhaps weak) group selected by the attacker. This is no worse than the current scenario and would require the attacker to be able to sign the ServerDHParams, which should not be possible without access to the server's secret key.

o 攻撃者が選択したカスタム（おそらく弱い）グループとDHE暗号スイートをネゴシエートすることにより、互換性のあるサーバーが実際には非互換であると偽装します。これは現在のシナリオよりも悪くはなく、攻撃者はServerDHParamsに署名できる必要があります。これは、サーバーの秘密鍵にアクセスすることなしには不可能です。

An attacker who impersonates the client can try to do the following:

クライアントを偽装する攻撃者は、次のことを試みることができます。

o Pretend that a compatible client is not compatible (e.g., by not offering the Supported Groups extension or by replacing the Supported Groups extension with one that includes no FFDHE groups). This could cause the server to negotiate a weaker DHE group during the handshake or to select a non-FFDHE cipher suite, but it would fail to complete during the final check of the Finished message.

o 互換性のあるクライアントに互換性がないように見せかけます（たとえば、サポートされているグループの拡張機能を提供しない、またはサポートされているグループの拡張機能をFFDHEグループを含まない拡張機能に置き換えるなど）。これにより、サーバーはハンドシェイク中に弱いDHEグループをネゴシエートしたり、FFDHE以外の暗号スイートを選択したりする可能性がありますが、完了メッセージの最終チェック中には完了できません。

o Pretend that a non-compatible client is compatible (e.g., by adding the Supported Groups extension or by adding FFDHE groups to the extension). This could cause the server to select a particular named group in the ServerKeyExchange or to avoid selecting an FFDHE cipher suite. The peers would fail to compute the final check of the Finished message.

o 互換性のないクライアントが互換性のあるふりをします（たとえば、サポートされているグループの拡張機能を追加するか、FFDHEグループを拡張機能に追加します）。これにより、サーバーはServerKeyExchangeで特定の名前付きグループを選択するか、FFDHE暗号スイートの選択を回避する可能性があります。ピアは、終了メッセージの最終チェックの計算に失敗します。

o Change the list of groups offered by the client (e.g., by removing the stronger of the set of groups offered). This could cause the server to negotiate a weaker group than desired, but again, should be caught by the check in the Finished message.

o クライアントから提供されたグループのリストを変更します（たとえば、提供されたグループのセットのうち強い方を削除するなど）。これにより、サーバーが必要以上に弱いグループをネゴシエートする可能性がありますが、ここでも、完了メッセージのチェックでキャッチする必要があります。

8.2. Group Strength Considerations

8.2. グループの強さに関する考慮事項

TLS implementations using FFDHE key exchange should consider the strength of the group they negotiate. The strength of the selected group is one of the factors that define the connection's resilience against attacks on the session's confidentiality and integrity, since the session keys are derived from the DHE handshake.

FFDHEキー交換を使用するTLS実装では、ネゴシエートするグループの強度を考慮する必要があります。セッションキーはDHEハンドシェイクから取得されるため、選択したグループの強度は、セッションの機密性と整合性に対する攻撃に対する接続の回復力を定義する要素の1つです。

While attacks on integrity must generally happen while the session is in progress, attacks against session confidentiality can happen significantly later if the entire TLS session is stored for offline analysis. Therefore, FFDHE groups should be selected by clients and servers based on confidentiality guarantees they need. Sessions that need extremely long-term confidentiality should prefer stronger groups.

整合性への攻撃は通常、セッションの進行中に発生する必要がありますが、オフライン分析用にTLSセッション全体が保存されている場合、セッションの機密性に対する攻撃が大幅に発生する可能性があります。したがって、FFDHEグループは、クライアントとサーバーが必要とする機密性の保証に基づいて選択する必要があります。非常に長期間の機密性が必要なセッションでは、より強力なグループを優先する必要があります。

[ENISA] provides rough estimates of group resistance to attack and recommends that forward-looking implementations ("future systems") should use FFDHE group sizes of at least 3072 bits. ffdhe3072 is intended for use in these implementations.

[ENISA]は、攻撃に対するグループの耐性の概算を提供し、将来を見据えた実装（「将来のシステム」）は、少なくとも3072ビットのFFDHEグループサイズを使用することを推奨しています。 ffdhe3072は、これらの実装での使用を目的としています。

Other sources (e.g., [NIST]) estimate the security levels of the Discrete Log (DLOG) problem to be slightly more difficult than [ENISA]. This document's suggested minimum exponent sizes in Appendix A for implementations that use the short-exponent optimization (Section 5.2) are deliberately conservative to account for the range of these estimates.

他のソース（[NIST]など）は、離散ログ（DLOG）問題のセキュリティレベルを[ENISA]よりも少し難しいと推定しています。このドキュメントで推奨されている、指数の最適化（5.2節）を使用する実装の付録Aに示されている最小の指数サイズは、これらの見積もりの範囲を考慮して慎重に保守されています。

8.3. Finite Field DHE Only

8.3. 有限体ANDのみ

Note that this document specifically targets only finite field Diffie-Hellman ephemeral key exchange mechanisms. It does not cover the non-ephemeral DH key exchange mechanisms, nor does it address ECDHE key exchange, which is defined in [RFC4492].

このドキュメントは、有限フィールドのDiffie-Hellman短期鍵交換メカニズムのみを対象としています。 [RFC4492]で定義されている非一時的なDH鍵交換メカニズムについては取り上げません。また、ECDHE鍵交換についても扱いません。

Measured by computational cost to the TLS peers, ECDHE appears today to offer a much stronger key exchange mechanism than FFDHE.

TLSピアの計算コストによって測定されるECDHEは、FFDHEよりもはるかに強力な鍵交換メカニズムを提供しているようです。

8.4. Deprecating Weak Groups

8.4. 弱いグループの廃止

Advances in hardware or in finite field cryptanalysis may cause some of the negotiated groups to not provide the desired security margins, as indicated by the estimated work factor of an adversary to discover the premaster secret (and may therefore compromise the confidentiality and integrity of the TLS session).

ハードウェアまたは有限フィールド暗号解読の進歩により、プレマスターシークレットを発見するための敵の推定作業係数によって示されるように、交渉されたグループの一部が望ましいセキュリティマージンを提供しない可能性があります（したがって、TLSの機密性と整合性が損なわれる可能性があります）セッション）。

Revisions of this document should mark known weak groups as explicitly deprecated for use in TLS and should update the estimated work factor needed to break the group if the cryptanalysis has changed. Implementations that require strong confidentiality and integrity guarantees should avoid using deprecated groups and should be updated when the estimated security margins are updated.

このドキュメントの改訂では、既知の脆弱なグループをTLSでの使用が明示的に非推奨としてマークし、暗号解読が変更された場合にグループを解体するために必要な推定作業係数を更新する必要があります。強力な機密性と整合性の保証を必要とする実装では、非推奨のグループの使用を避け、推定セキュリティマージンが更新されたときに更新する必要があります。

8.5. Choice of Groups

8.5. グループの選択

Other lists of named finite field Diffie-Hellman groups [STRONGSWAN-IKE] exist. This document chooses to not reuse them for several reasons:

名前付き有限フィールドDiffie-Hellmanグループ[STRONGSWAN-IKE]の他のリストが存在します。このドキュメントでは、いくつかの理由でそれらを再利用しないことにしました。

o Using the same groups in multiple protocols increases the value for an attacker with the resources to crack any single group.

o 複数のプロトコルで同じグループを使用すると、単一のグループをクラックするリソースを持つ攻撃者の価値が高まります。

o The Internet Key Exchange Protocol (IKE) groups include weak groups like MODP768 that are unacceptable for secure TLS traffic.

o Internet Key Exchange Protocol（IKE）グループには、セキュアなTLSトラフィックを受け入れることができないMODP768などの弱いグループが含まれます。

o Mixing group parameters across multiple implementations leaves open the possibility of some sort of cross-protocol attack. This shouldn't be relevant for ephemeral scenarios, and even with non-ephemeral keying, services shouldn't share keys; however, using different groups avoids these failure modes entirely.

o 複数の実装間でグループパラメータを混在させると、ある種のクロスプロトコル攻撃の可能性が残ります。これは一時的なシナリオには関係ありません。また、一時的ではないキーを使用する場合でも、サービスはキーを共有しないでください。ただし、異なるグループを使用すると、これらの障害モードが完全に回避されます。

8.6. Timing Attacks

8.6. タイミング攻撃

Any implementation of finite field Diffie-Hellman key exchange should use constant-time modular-exponentiation implementations. This is particularly true for those implementations that ever reuse DHE secret keys (so-called "semi-static" ephemeral keying) or share DHE secret keys across a multiple machines (e.g., in a load-balancer situation).

有限体Diffie-Hellman鍵交換の実装では、定数時間のべき乗剰余実装を使用する必要があります。これは、DHE秘密鍵を再利用する（いわゆる「半静的」一時キーイング）、または複数のマシン間で（たとえば、ロードバランサーの状況で）DHE秘密鍵を共有する実装に特に当てはまります。

8.7. Replay Attacks from Non-negotiated FFDHE

8.7. 交渉されていないFFDHEからのリプレイ攻撃

[SECURE-RESUMPTION], [CROSS-PROTOCOL], and [SSL3-ANALYSIS] all show a malicious peer using a bad FFDHE group to maneuver a client into selecting a premaster secret of the peer's choice, which can be replayed to another server using a non-FFDHE key exchange and can then be bootstrapped to replay client authentication.

[SECURE-RESUMPTION]、[CROSS-PROTOCOL]、および[SSL3-ANALYSIS]はすべて、悪意のあるピアが不正なFFDHEグループを使用して、クライアントがピアの選択のプリマスターシークレットを選択するように操作し、それを使用して別のサーバーに再生できることを示しています。非FFDHE鍵交換。ブートストラップしてクライアント認証を再生できます。

To prevent this attack (barring the session hash fix documented in [RFC7627]), a client would need not only to implement this document, but also to reject non-negotiated FFDHE cipher suites whose group structure it cannot afford to verify. Such a client would need to abort the initial handshake and reconnect to the server in question without listing any FFDHE cipher suites on the subsequent connection.

この攻撃を防ぐには（[RFC7627]に文書化されているセッションハッシュの修正を除く）、クライアントはこの文書を実装するだけでなく、グループ構造を検証する余裕のない交渉されていないFFDHE暗号スイートを拒否する必要があります。このようなクライアントは、その後の接続でFFDHE暗号スイートをリストせずに、初期のハンドシェイクを中止して問題のサーバーに再接続する必要があります。

This trade-off may be too costly for most TLS clients today but may be a reasonable choice for clients performing client certificate authentication or for clients who have other reasons to be concerned about server-controlled premaster secrets.

このトレードオフは、今日のほとんどのTLSクライアントにとってコストがかかりすぎる可能性がありますが、クライアント証明書認証を実行するクライアントや、サーバー制御のプリマスターシークレットを懸念する他の理由があるクライアントにとっては妥当な選択かもしれません。

8.8. Forward Secrecy

8.8. 秘密の転送

One of the main reasons to prefer FFDHE ciphersuites is forward secrecy, the ability to resist decryption even if the endpoint's long-term secret key (usually RSA) is revealed in the future.

FFDHE暗号スイートを選択する主な理由の1つは、前方機密性です。これは、エンドポイントの長期的な秘密鍵（通常はRSA）が将来明らかになったとしても、解読に抵抗する能力です。

This property depends on both sides of the connection discarding their ephemeral keys promptly. Implementations should wipe their FFDHE secret key material from memory as soon as it is no longer needed and should never store it in persistent storage.

このプロパティは、エフェメラルキーをすぐに破棄する接続の両側に依存します。実装では、FFDHE秘密鍵のマテリアルが不要になり次第、メモリから消去し、永続的なストレージに保存しないでください。

Forward secrecy also depends on the strength of the Diffie-Hellman group; using a very strong symmetric cipher like AES256 with a forward-secret cipher suite but generating the keys with a much weaker group like dhe2048 simply moves the adversary's cost from attacking the symmetric cipher to attacking the dh_Ys or dh_Yc ephemeral key shares.

前方秘密は、Diffie-Hellmanグループの強さにも依存します。 AES256のような非常に強力な対称暗号とフォワードシークレット暗号スイートを使用しますが、dhe2048のようなはるかに弱いグループで鍵を生成すると、敵のコストが対称暗号の攻撃からdh_Ysまたはdh_Ycの一時鍵共有の攻撃に移されます。

If the goal is to provide forward secrecy, attention should be paid to all parts of the cipher suite selection process, both key exchange and symmetric cipher choice.

転送秘密を提供することを目的とする場合は、暗号スイート選択プロセスのすべての部分（鍵交換と対称暗号の選択の両方）に注意を払う必要があります。

8.9. False Start

8.9. 誤ったスタート

Clients capable of TLS False Start [RFC7918] may receive a proposed FFDHE group from a server that is attacker controlled. In particular, the attacker can modify the ClientHello to strip the proposed FFDHE groups, which may cause the server to offer a weaker FFDHE group than it should, and this will not be detected until receipt of the server's Finished message. This could cause a client using the False Start protocol modification to send data encrypted under a weak key agreement.

TLS False Start [RFC7918]が可能なクライアントは、攻撃者が制御するサーバーから提案されたFFDHEグループを受信する可能性があります。特に、攻撃者はClientHelloを変更して、提案されたFFDHEグループを取り除くことができます。これにより、サーバーが提供するよりも弱いFFDHEグループを提供する可能性があり、これはサーバーの完了メッセージを受信するまで検出されません。これにより、False Startプロトコルの変更を使用するクライアントが、弱い鍵協定の下で暗号化されたデータを送信する可能性があります。

Clients should have their own classification of FFDHE groups that are "cryptographically strong" in the same sense described in the description of symmetric ciphers in [RFC7918] and SHOULD offer at least one of these in the initial handshake if they contemplate using the False Start protocol modification with an FFDHE cipher suite.

クライアントは、[RFC7918]の対称暗号の説明で説明されているのと同じ意味で「暗号的に強い」FFDHEグループの独自の分類を持つ必要があり、False Startプロトコルの使用を検討している場合、最初のハンドシェイクでこれらのグループの少なくとも1つを提供する必要があります。 FFDHE暗号スイートによる変更。

Compatible clients performing a full handshake MUST NOT use the False Start protocol modification if the server selects an FFDHE cipher suite but sends a group that is not cryptographically strong from the client's perspective.

完全なハンドシェイクを実行する互換性のあるクライアントは、サーバーがFFDHE暗号スイートを選択したが、クライアントの観点から暗号的に強力ではないグループを送信する場合、False Startプロトコルの変更を使用してはなりません。

9. Privacy Considerations

9. プライバシーに関する考慮事項

9.1. Client Fingerprinting

9.1. クライアントのフィンガープリント

This extension provides a few additional bits of information to distinguish between classes of TLS clients (e.g., see [PANOPTICLICK]). To minimize this sort of fingerprinting, clients SHOULD support all named groups at or above their minimum security threshold. New groups SHOULD NOT be added to the "Supported Groups Registry" without consideration of the cost of browser fingerprinting.

この拡張機能は、TLSクライアントのクラスを区別するためのいくつかの追加情報を提供します（たとえば、[PANOPTICLICK]を参照）。この種のフィンガープリントを最小限に抑えるために、クライアントは最小セキュリティしきい値以上のすべての名前付きグループをサポートする必要があります（SHOULD）。ブラウザのフィンガープリントのコストを考慮せずに、「サポートされるグループレジストリ」に新しいグループを追加してはなりません。

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.

[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、DOI 10.17487 / RFC4492、2006年5月、<http://www.rfc-editor.org/info/rfc4492>。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。

[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", DOI 10.17487/RFC7918, June 2016, <http://www.rfc-editor.org/info/rfc7918>.

[RFC7918] Langley、A.、Modadugu、N。、およびB. Moeller、「Transport Layer Security（TLS）False Start」、DOI 10.17487 / RFC7918、2016年6月、<http://www.rfc-editor.org/ info / rfc7918>。

10.2. Informative References

10.2. 参考引用

[CROSS-PROTOCOL] Mavrogiannopolous, N., Vercauteren, F., Velichkov, V., and B. Preneel, "A Cross-Protocol Attack on the TLS Protocol", In Proceedings of the 2012 ACM Conference on Computer and Communications Security, DOI 10.1145/2382196.2382206, October 2012, <http://www.cosic.esat.kuleuven.be/ publications/article-2216.pdf>.

[CROSS-PROTOCOL] Mavrogiannopolous、N.、Vercauteren、F.、Velichkov、V。、およびB. Preneel、「TLSプロトコルへのクロスプロトコル攻撃」、2012 ACM Conference on Computer and Communications Security、 DOI 10.1145 / 2382196.2382206、2012年10月、<http://www.cosic.esat.kuleuven.be/ Publications / article-2216.pdf>。

[ECRYPTII] European Network of Excellence in Cryptology II, "ECRYPT II Yearly Report on Algorithms and Keysizes (2011-2012)", Revision 1.0, September 2012, <http://www.ecrypt.eu.org/ecrypt2/documents/D.SPA.20.pdf>.

[ECRYPTII]暗号学IIのEuropean Network of Excellence、「アルゴリズムとキーサイズに関するECRYPT II年次報告書（2011-2012）」、リビジョン1.0、2012年9月、<http://www.ecrypt.eu.org/ecrypt2/documents/ D.SPA.20.pdf>。

[ENISA] European Union Agency for Network and Information Security (ENISA), "Algorithms, Key Sizes and Parameters Report - 2014", November 2014, <https://www.enisa.europa.eu/publications/ algorithms-key-size-and-parameters-report-2014>.

[ENISA]欧州連合ネットワーク情報セキュリティ局（ENISA）、「アルゴリズム、キーサイズとパラメータレポート-2014」、2014年11月、<https://www.enisa.europa.eu/publications/ algorithm-key-size -and-parameters-report-2014>。

[NIST] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General", NIST Special Publication 800-57, Revision 4, DOI 10.6028/NIST.SP.800-57pt1r4, January 2016, <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>.

[NIST] National Institute of Standards and Technology、「Recommendation for Key Management-Part 1：General」、NIST Special Publication 800-57、Revision 4、DOI 10.6028 / NIST.SP.800-57pt1r4、January、<http：/ /nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57pt1r4.pdf>。

[PANOPTICLICK] Electronic Frontier Foundation, "Panopticlick: Is your browser safe against tracking?", <https://panopticlick.eff.org/>.

[PANOPTICLICK] Electronic Frontier Foundation、「Panopticlick：お使いのブラウザーは追跡に対して安全ですか？」、<https://panopticlick.eff.org/>。

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <http://www.rfc-editor.org/info/rfc2246>.

[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、DOI 10.17487 / RFC2246、1999年1月、<http://www.rfc-editor.org/info/rfc2246>。

[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, DOI 10.17487/RFC3526, May 2003, <http://www.rfc-editor.org/info/rfc3526>.

[RFC3526] Kivinen、T。、およびM. Kojo、「インターネット鍵交換（IKE）用のModular Exponential（MODP）Diffie-Hellmanグループ」、RFC 3526、DOI 10.17487 / RFC3526、2003年5月、<http：// www。 rfc-editor.org/info/rfc3526>。

[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <http://www.rfc-editor.org/info/rfc4346>.

[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、DOI 10.17487 / RFC4346、2006年4月、<http://www.rfc-editor.org/info / rfc4346>。

[RFC4419] Friedl, M., Provos, N., and W. Simpson, "Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, DOI 10.17487/RFC4419, March 2006, <http://www.rfc-editor.org/info/rfc4419>.

[RFC4419] Friedl、M.、Provos、N。、およびW. Simpson、「Diffie-Hellman Group Exchange for the Secure Shell（SSH）Transport Layer Protocol」、RFC 4419、DOI 10.17487 / RFC4419、2006年3月、<http： //www.rfc-editor.org/info/rfc4419>。

[RFC7027] Merkle, J. and M. Lochter, "Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)", RFC 7027, DOI 10.17487/RFC7027, October 2013, <http://www.rfc-editor.org/info/rfc7027>.

[RFC7027] Merkle、J。およびM. Lochter、「トランスポート層セキュリティ（TLS）のための楕円曲線暗号（ECC）ブレインプール曲線」、RFC 7027、DOI 10.17487 / RFC7027、2013年10月、<http：//www.rfc- editor.org/info/rfc7027>。

[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, <http://www.rfc-editor.org/info/rfc7627>.

[RFC7627] Bhargavan、K。、編、Delignat-Lavaud、A.、Pironti、A.、Langley、A。、およびM. Ray、「Transport Layer Security（TLS）Session Hash and Extended Master Secret Extension」、RFC 7627、DOI 10.17487 / RFC7627、2015年9月、<http://www.rfc-editor.org/info/rfc7627>。

[SECURE-RESUMPTION] Delignat-Lavaud, A., Bhargavan, K., and A. Pironti, "Triple Handshakes Considered Harmful: Breaking and Fixing Authentication over TLS", 2014 IEEE Symposium on Security and Privacy, DOI 10.1109/SP.2014.14, March 2014, <https://secure-resumption.com/>.

[SECURE-RESUMPTION] Delignat-Lavaud、A.、Bhargavan、K。、およびA. Pironti、「有害と見なされる3つのハンドシェイク：TLSを介した認証の破壊と修正」、2014年セキュリティとプライバシーに関するIEEEシンポジウム、DOI 10.1109 / SP.2014.14 、2014年3月、<https://secure-resumption.com/>。

[SSL3-ANALYSIS] Schneier, B. and D. Wagner, "Analysis of the SSL 3.0 protocol", In Proceedings of the Second UNIX Workshop on Electronic Commerce, 1996, <https://www.schneier.com/paper-ssl.pdf>.

[SSL3-ANALYSIS] Schneier、B。およびD. Wagner、「Analysis of the SSL 3.0 protocol」、Proceedings of the Second UNIX Workshop on Electronic Commerce、1996、<https://www.schneier.com/paper-ssl .pdf>。

[STRONGSWAN-IKE] Brunner, T. and A. Steffen, "IKEv2 Cipher Suites: Diffie Hellman Groups", October 2013, <https://wiki.strongswan.org/projects/strongswan/wiki/ IKEv2CipherSuites#Diffie-Hellman-Groups>.

[STRONGSWAN-IKE] Brunner、T。およびA. Steffen、「IKEv2 Cipher Suites：Diffie Hellman Groups」、2013年10月、<https://wiki.strongswan.org/projects/strongswan/wiki/ IKEv2CipherSuites＃Diffie-Hellman-グループ>。

Appendix A. Supported Groups Registry (Formerly "EC Named Curve Registry")

付録A.サポートされるグループレジストリ（以前の「EC名前付き曲線レジストリ」）

Each description below indicates the group itself, its derivation, its expected strength (estimated roughly from guidelines in [ECRYPTII]), and whether it is recommended for use in TLS key exchange at the given security level. It is not recommended to add further finite field groups to the "Supported Groups Registry"; any attempt to do so should consider Section 9.1.

以下の各説明は、グループ自体、その派生、予想される強度（[ECRYPTII]のガイドラインから概算）、および特定のセキュリティレベルでのTLSキー交換での使用が推奨されるかどうかを示しています。「サポートされているグループレジストリ」にさらに有限フィールドグループを追加することはお勧めしません。そうするあらゆる試みはセクション9.1を考慮する必要があります。

   The primes in these finite field groups are all safe primes; that is,
   a prime p is a safe prime when q = (p-1)/2 is also prime.  Where e is
   the base of the natural logarithm and square brackets denote the
   floor operation, the groups that initially populate this registry are
   derived for a given bit length b by finding the lowest positive
   integer X that creates a safe prime p where:

    p = 2^b - 2^{b-64} + {[2^{b-130} e] + X } * 2^64 - 1

New additions of FFDHE groups to this registry may use this same derivation (e.g., with different bit lengths) or may choose their parameters in a different way, but they must be clear about how the parameters were derived.

このレジストリへのFFDHEグループの新たな追加は、これと同じ派生（たとえば、異なるビット長で）を使用するか、またはそれらのパラメーターを異なる方法で選択する可能性がありますが、パラメーターがどのように派生したかについて明確でなければなりません。

New additions of FFDHE groups MUST use a safe prime as the modulus to enable the inexpensive peer verification described in Section 5.1.

FFDHEグループの新たな追加では、セクション5.1で説明されている安価なピア検証を可能にするために、係数として安全な素数を使用する必要があります。

A.1. ffdhe2048

The 2048-bit group has registry value 256 and is calculated from the following formula:

2048ビットグループにはレジストリ値256があり、次の式から計算されます。

The modulus is:

係数は次のとおりです。

p = 2^2048 - 2^1984 + {[2^1918 * e] + 560316 } * 2^64 - 1 The hexadecimal representation of p is:

p = 2 ^ 2048-2 ^ 1984 + {[2 ^ 1918 * e] + 560316} * 2 ^ 64-1 pの16進数表現は次のとおりです。

The generator is: g = 2

ジェネレータは次のとおりです：g = 2

   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

qの16進数表現は次のとおりです。

The estimated symmetric-equivalent strength of this group is 103 bits.

このグループの推定対称等価強度は103ビットです。

Peers using ffdhe2048 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 225 bits.

短い指数（セクション5.2）で鍵交換を最適化したいffdhe2048を使用するピアは、少なくとも225ビットの秘密鍵を選択する必要があります。

A.2. ffdhe3072

A.2. それで彼は恐れられました072

The 3072-bit prime has registry value 257 and is calculated from the following formula:

3072ビットの素数にはレジストリ値257があり、次の式から計算されます。

The modulus is:

係数は次のとおりです。

p = 2^3072 - 2^3008 + {[2^2942 * e] + 2625351} * 2^64 - 1 The hexadecimal representation of p is:

p = 2 ^ 3072-2 ^ 3008 + {[2 ^ 2942 * e] + 2625351} * 2 ^ 64-1 pの16進数表現は次のとおりです。

The generator is: g = 2

ジェネレータは次のとおりです：g = 2

   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

qの16進数表現は次のとおりです。

The estimated symmetric-equivalent strength of this group is 125 bits.

このグループの推定対称等価強度は125ビットです。

Peers using ffdhe3072 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 275 bits.

短い指数（セクション5.2）で鍵交換を最適化したいffdhe3072を使用するピアは、少なくとも275ビットの秘密鍵を選択する必要があります。

A.3. ffdhe4096

The 4096-bit group has registry value 258 and is calculated from the following formula:

4096ビットグループにはレジストリ値258があり、次の式から計算されます。

The modulus is:

係数は次のとおりです。

   p = 2^4096 - 2^4032 + {[2^3966 * e] + 5736041} * 2^64 - 1

The hexadecimal representation of p is:

pの16進数表現は次のとおりです。

The generator is: g = 2

ジェネレータは次のとおりです：g = 2

   The group size is: q = (p-1)/2
   The hexadecimal representation of q is:

The estimated symmetric-equivalent strength of this group is 150 bits.

このグループの推定対称等価強度は150ビットです。

Peers using ffdhe4096 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 325 bits.

短い指数（セクション5.2）でキー交換を最適化したいffdhe4096を使用するピアは、少なくとも325ビットの秘密キーを選択する必要があります。

A.4. ffdhe6144

The 6144-bit group has registry value 259 and is calculated from the following formula:

6144ビットグループにはレジストリ値259があり、次の式から計算されます。

The modulus is:

係数は次のとおりです。

p = 2^6144 - 2^6080 + {[2^6014 * e] + 15705020} * 2^64 - 1 The hexadecimal representation of p is:

p = 2 ^ 6144-2 ^ 6080 + {[2 ^ 6014 * e] + 15705020} * 2 ^ 64-1 pの16進数表現は次のとおりです。

FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 A907600A 918130C4 6DC778F9 71AD0038 092999A3 33CB8B7A 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF

FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 A907600A 918130C4 6DC778F9 7 1AD0038 092999A3 33CB8B7A 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 A41D570D 7938DAD4 A40E329C D0E40E65 FFFFFFFF FFFFFFFF

The generator is: g = 2

ジェネレータは次のとおりです：g = 2

   The group size is: q = (p-1)/2
   The hexadecimal representation of q is:

7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 5483B005 48C09862 36E3BC7C B8D6801C 0494CCD1 99E5C5BD 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 D20EAB86 BC9C6D6A 5207194E 68720732 FFFFFFFF FFFFFFFF

7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 5483B005 48C09862 36E3BC7C B 8D6801C 0494CCD1 99E5C5BD 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 D20EAB86 BC9C6D6A 5207194E 68720732 FFFFFFFF FFFFFFFF

The estimated symmetric-equivalent strength of this group is 175 bits.

このグループの推定対称等価強度は175ビットです。

Peers using ffdhe6144 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 375 bits.

短い指数（セクション5.2）で鍵交換を最適化したいffdhe6144を使用するピアは、少なくとも375ビットの秘密鍵を選択する必要があります。

A.5. ffdhe8192

The 8192-bit group has registry value 260 and is calculated from the following formula:

8192ビットグループのレジストリ値は260で、次の式から計算されます。

The modulus is:

係数は次のとおりです。

p = 2^8192 - 2^8128 + {[2^8062 * e] + 10965728} * 2^64 - 1 The hexadecimal representation of p is:

p = 2 ^ 8192-2 ^ 8128 + {[2 ^ 8062 * e] + 10965728} * 2 ^ 64-1 pの16進数表現は次のとおりです。

FFFFFFFF FFFFFFFF ADF85458 A2BB4A9A AFDC5620 273D3CF1 D8B9C583 CE2D3695 A9E13641 146433FB CC939DCE 249B3EF9 7D2FE363 630C75D8 F681B202 AEC4617A D3DF1ED5 D5FD6561 2433F51F 5F066ED0 85636555 3DED1AF3 B557135E 7F57C935 984F0C70 E0E68B77 E2A689DA F3EFE872 1DF158A1 36ADE735 30ACCA4F 483A797A BC0AB182 B324FB61 D108A94B B2C8E3FB B96ADAB7 60D7F468 1D4F42A3 DE394DF4 AE56EDE7 6372BB19 0B07A7C8 EE0A6D70 9E02FCE1 CDF7E2EC C03404CD 28342F61 9172FE9C E98583FF 8E4F1232 EEF28183 C3FE3B1B 4C6FAD73 3BB5FCBC 2EC22005 C58EF183 7D1683B2 C6F34A26 C1B2EFFA 886B4238 611FCFDC DE355B3B 6519035B BC34F4DE F99C0238 61B46FC9 D6E6C907 7AD91D26 91F7F7EE 598CB0FA C186D91C AEFE1309 85139270 B4130C93 BC437944 F4FD4452 E2D74DD3 64F2E21E 71F54BFF 5CAE82AB 9C9DF69E E86D2BC5 22363A0D ABC52197 9B0DEADA 1DBF9A42 D5C4484E 0ABCD06B FA53DDEF 3C1B20EE 3FD59D7C 25E41D2B 669E1EF1 6E6F52C3 164DF4FB 7930E9E4 E58857B6 AC7D5F42 D69F6D18 7763CF1D 55034004 87F55BA5 7E31CC7A 7135C886 EFB4318A ED6A1E01 2D9E6832 A907600A 918130C4 6DC778F9 7 1AD0038 092999A3 33CB8B7A 1A1DB93D 7140003C 2A4ECEA9 F98D0ACC 0A8291CD CEC97DCF 8EC9B55A 7F88A46B 4DB5A851 F44182E1 C68A007E 5E0DD902 0BFD64B6 45036C7A 4E677D2C 38532A3A 23BA4442 CAF53EA6 3BB45432 9B7624C8 917BDD64 B1C0FD4C B38E8C33 4C701C3A CDAD0657 FCCFEC71 9B1F5C3E 4E46041F 388147FB 4CFDB477 A52471F7 A9A96910 B855322E DB6340D8 A00EF092 350511E3 0ABEC1FF F9E3A26E 7FB29F8C 183023C3 587E38DA 0077D9B4 763E4E4B 94B2BBC1 94C6651E 77CAF992 EEAAC023 2A281BF6 B3A739C1 22611682 0AE8DB58 47A67CBE F9C9091B 462D538C D72B0374 6AE77F5E 62292C31 1562A846 505DC82D B854338A E49F5235 C95B9117 8CCF2DD5 CACEF403 EC9D1810 C6272B04 5B3B71F9 DC6B80D6 3FDD4A8E 9ADB1E69 62A69526 D43161C1 A41D570D 7938DAD4 A40E329C CFF46AAA 36AD004C F600C838 1E425A31 D951AE64 FDB23FCE C9509D43 687FEB69 EDD1CC5E 0B8CC3BD F64B10EF 86B63142 A3AB8829 555B2F74 7C932665 CB2C0F1C C01BD702 29388839 D2AF05E4 54504AC7 8B758282 2846C0BA 35C35F5C 59160CC0 46FD8251 541FC68C 9C86B022 BB709987 6A460E74 51A8A931 09703FEE 1C217E6C 3826E52C 51 AA691E 0E423CFC 99E9E316 50C1217B 624816CD AD9A95F9 D5B80194 88D9C0A0 A1FE3075 A577E231 83F81D4A 3F2FA457 1EFC8CE0 BA8A4FE8 B6855DFE 72B0A66E DED2FBAB FBE58A30 FAFABE1C 5D71A87E 2F741EF8 C1FE86FE A6BBFDE5 30677F0D 97D11D49 F7A8443D 0822E506 A9F4614E 011E2A94 838FF88C D68C8BB7 C5C6424C FFFFFFFF FFFFFFFF

   The generator is: g = 2
   The group size is: q = (p-1)/2

The hexadecimal representation of q is:

qの16進数表現は次のとおりです。

7FFFFFFF FFFFFFFF D6FC2A2C 515DA54D 57EE2B10 139E9E78 EC5CE2C1 E7169B4A D4F09B20 8A3219FD E649CEE7 124D9F7C BE97F1B1 B1863AEC 7B40D901 576230BD 69EF8F6A EAFEB2B0 9219FA8F AF833768 42B1B2AA 9EF68D79 DAAB89AF 3FABE49A CC278638 707345BB F15344ED 79F7F439 0EF8AC50 9B56F39A 98566527 A41D3CBD 5E0558C1 59927DB0 E88454A5 D96471FD DCB56D5B B06BFA34 0EA7A151 EF1CA6FA 572B76F3 B1B95D8C 8583D3E4 770536B8 4F017E70 E6FBF176 601A0266 941A17B0 C8B97F4E 74C2C1FF C7278919 777940C1 E1FF1D8D A637D6B9 9DDAFE5E 17611002 E2C778C1 BE8B41D9 6379A513 60D977FD 4435A11C 308FE7EE 6F1AAD9D B28C81AD DE1A7A6F 7CCE011C 30DA37E4 EB736483 BD6C8E93 48FBFBF7 2CC6587D 60C36C8E 577F0984 C289C938 5A098649 DE21BCA2 7A7EA229 716BA6E9 B279710F 38FAA5FF AE574155 CE4EFB4F 743695E2 911B1D06 D5E290CB CD86F56D 0EDFCD21 6AE22427 055E6835 FD29EEF7 9E0D9077 1FEACEBE 12F20E95 B34F0F78 B737A961 8B26FA7D BC9874F2 72C42BDB 563EAFA1 6B4FB68C 3BB1E78E AA81A002 43FAADD2 BF18E63D 389AE443 77DA18C5 76B50F00 96CF3419 5483B005 48C09862 36E3BC7C B 8D6801C 0494CCD1 99E5C5BD 0D0EDC9E B8A0001E 15276754 FCC68566 054148E6 E764BEE7 C764DAAD 3FC45235 A6DAD428 FA20C170 E345003F 2F06EC81 05FEB25B 2281B63D 2733BE96 1C29951D 11DD2221 657A9F53 1DDA2A19 4DBB1264 48BDEEB2 58E07EA6 59C74619 A6380E1D 66D6832B FE67F638 CD8FAE1F 2723020F 9C40A3FD A67EDA3B D29238FB D4D4B488 5C2A9917 6DB1A06C 50077849 1A8288F1 855F60FF FCF1D137 3FD94FC6 0C1811E1 AC3F1C6D 003BECDA 3B1F2725 CA595DE0 CA63328F 3BE57CC9 77556011 95140DFB 59D39CE0 91308B41 05746DAC 23D33E5F 7CE4848D A316A9C6 6B9581BA 3573BFAF 31149618 8AB15423 282EE416 DC2A19C5 724FA91A E4ADC88B C66796EA E5677A01 F64E8C08 63139582 2D9DB8FC EE35C06B 1FEEA547 4D6D8F34 B1534A93 6A18B0E0 D20EAB86 BC9C6D6A 5207194E 67FA3555 1B568026 7B00641C 0F212D18 ECA8D732 7ED91FE7 64A84EA1 B43FF5B4 F6E8E62F 05C661DE FB258877 C35B18A1 51D5C414 AAAD97BA 3E499332 E596078E 600DEB81 149C441C E95782F2 2A282563 C5BAC141 1423605D 1AE1AFAE 2C8B0660 237EC128 AA0FE346 4E435811 5DB84CC3 B523073A 28D45498 84B81FF7 0E10BF36 1C137296 28 D5348F 07211E7E 4CF4F18B 286090BD B1240B66 D6CD4AFC EADC00CA 446CE050 50FF183A D2BBF118 C1FC0EA5 1F97D22B 8F7E4670 5D4527F4 5B42AEFF 39585337 6F697DD5 FDF2C518 7D7D5F0E 2EB8D43F 17BA0F7C 60FF437F 535DFEF2 9833BF86 CBE88EA4 FBD4221E 84117283 54FA30A7 008F154A 41C7FC46 6B4645DB E2E32126 7FFFFFFF FFFFFFFF

The estimated symmetric-equivalent strength of this group is 192 bits.

このグループの推定対称等価強度は192ビットです。

Peers using ffdhe8192 that want to optimize their key exchange with a short exponent (Section 5.2) should choose a secret key of at least 400 bits.

短い指数（セクション5.2）で鍵交換を最適化したいffdhe8192を使用するピアは、少なくとも400ビットの秘密鍵を選択する必要があります。

Acknowledgements

謝辞

Thanks to Fedor Brunner, Dave Fergemann, Niels Ferguson, Sandy Harris, Tero Kivinen, Watson Ladd, Nikos Mavrogiannopolous, Niels Moeller, Bodo Moeller, Kenny Paterson, Eric Rescorla, Tom Ritter, Rene Struik, Martin Thomson, Sean Turner, and other members of the TLS Working Group for their comments and suggestions on this document. Any mistakes here are not theirs.

Fedor Brunner、Dave Fergemann、Niels Ferguson、Sandy Harris、Tero Kivinen、Watson Ladd、Nikos Mavrogiannopolous、Niels Moeller、Bodo Moeller、Kenny Paterson、Eric Rescorla、Tom Ritter、Rene Struik、Martin Thomson、Sean Turner、その他のメンバーに感謝このドキュメントに関するコメントと提案については、TLSワーキンググループのメンバー。ここでのミスは彼らのミスではありません。

Author's Address

著者のアドレス

Daniel Kahn Gillmor ACLU 125 Broad Street, 18th Floor New York, NY 10004 United States of America

Daniel Kahn Gillmor ACLU 125 Broad Street、18th Floor New York、NY 10004アメリカ合衆国

   Email: dkg@fifthhorseman.net