Internet Engineering Task Force (IETF) K. Kwiatkowski
Request for Comments: 10024 PQShield
Category: Standards Track P. Kampanakis
ISSN: 2070-1721 AWS
B. E. Westerbaan
Cloudflare
D. Stebila
University of Waterloo
August 2026
This document defines three hybrid key agreement mechanisms for TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Ephemeral Elliptic Curve Diffie-Hellman) exchange.
この文書は、ポスト量子 ML-KEM (モジュール格子ベースの鍵カプセル化メカニズム) と ECDHE (一時楕円曲線) を組み合わせた、TLS 1.3 の 3 つのハイブリッド鍵合意メカニズム (X25519MLKEM768、SecP256r1MLKEM768、および SecP384r1MLKEM1024) を定義します。ディフィー・ヘルマン）交換。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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 https://www.rfc-editor.org/info/rfc10024.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10024 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Motivation
3. Terminology
4. Negotiated Groups
4.1. Client Share
4.2. Server Share
4.3. Shared Secret
5. Regulatory Context
6. Security Considerations
7. IANA Considerations
7.1. X25519MLKEM768
7.2. SecP256r1MLKEM768
7.3. SecP384r1MLKEM1024
7.4. Obsoleted Supported Groups
8. References
8.1. Normative References
8.2. Informative References
Authors' Addresses
ML-KEM is a key encapsulation mechanism (KEM) defined in [NIST-FIPS-203]. It is designed to withstand cryptanalytic attacks from quantum computers.
ML-KEM は、[NIST-FIPS-203] で定義されている鍵カプセル化メカニズム (KEM) です。量子コンピューターからの暗号解読攻撃に耐えるように設計されています。
[RFC9954] defines a framework for combining traditional key exchanges with next-generation key exchange in TLS 1.3. The goal of this approach is to provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols.
[RFC9954] は、従来の鍵交換と TLS 1.3 の次世代鍵交換を組み合わせるためのフレームワークを定義しています。このアプローチの目標は、既存のインフラストラクチャおよびプロトコルとの互換性を維持しながら、古典的な敵対者と量子の敵対者の両方に対するセキュリティを提供することです。
This document applies the framework in [RFC9954] to ML-KEM and specifies code points for the hybrid groups.
この文書は、[RFC9954] のフレームワークを ML-KEM に適用し、ハイブリッド グループのコード ポイントを指定します。
This document introduces three new supported groups for Post-Quantum Traditional (PQ/T) hybrid key agreements [RFC9794] in TLS 1.3 -- X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 -- that combine ML-KEM with Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) in the manner described in [RFC9954]. Any of the hybrid groups specified in this document may be implemented in a FIPS-approved way as discussed in Section 5.
この文書では、TLS 1.3 の Post-Quantum Traditional (PQ/T) ハイブリッド鍵協定 [RFC9794] で新たにサポートされる 3 つのグループ、X25519MLKEM768、SecP256r1MLKEM768、および SecP384r1MLKEM1024 を紹介します。これらは、ML-KEM と一時楕円曲線 Diffie-Hellman (ECDHE) を組み合わせたものです。[RFC9954]に記載されている方法。この文書で指定されているハイブリッド グループはいずれも、セクション 5 で説明されている FIPS 承認の方法で実装できます。
* The first group uses X25519 [RFC7748], is widely deployed, and often serves as the most practical choice for a single PQ/T hybrid combiner [RFC9794] in TLS 1.3.
* 最初のグループは X25519 [RFC7748] を使用し、広く導入されており、多くの場合、TLS 1.3 の単一 PQ/T ハイブリッド コンバイナー [RFC9794] の最も実用的な選択肢として機能します。
* The second group uses secp256r1 (NIST P-256) [NIST-FIPS-186]. This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms.
* 2 番目のグループは secp256r1 (NIST P-256) [NIST-FIPS-186] を使用します。このグループは、FIPS 承認メカニズムによって両方の共有シークレットを生成する必要があるユースケースをサポートします。
* The third group uses secp384r1 (NIST P-384) [NIST-FIPS-186]. This group is intended for high-security environments that require FIPS-approved mechanisms with an increased security margin.
* 3 番目のグループは secp384r1 (NIST P-384) [NIST-FIPS-186] を使用します。このグループは、セキュリティ マージンが強化された FIPS 承認のメカニズムを必要とする高セキュリティ環境を対象としています。
Key establishment using NIST curves is outlined in Section 6.1.2.2 of [NIST-SP-800-56A].
NIST 曲線を使用した鍵の確立については、[NIST-SP-800-56A] のセクション 6.1.2.2 で概説されています。
[RFC9954] defines "traditional" algorithms as those that are already widely adopted and "next-generation" algorithms as those that are not yet widely adopted, such as post-quantum algorithms. In this document, ECDHE using Curve25519, P-256, or P-384 is considered traditional, while ML-KEM is considered next-generation.
[RFC9954] は、「従来の」アルゴリズムをすでに広く採用されているアルゴリズム、「次世代」アルゴリズムをポスト量子アルゴリズムなどまだ広く採用されていないアルゴリズムと定義しています。このドキュメントでは、Curve25519、P-256、または P-384 を使用する ECDHE は従来型とみなされ、ML-KEM は次世代とみなされます。
[RFC9954] also defines a "hybrid" key exchange as the simultaneous use of multiple key exchange algorithms, with their outputs combined to provide security as long as at least one of the component algorithms remains secure, even if the others are compromised. This document uses the term "hybrid" with the same meaning.
また、[RFC9954] では、「ハイブリッド」鍵交換を、複数の鍵交換アルゴリズムの同時使用として定義しており、コンポーネントのアルゴリズムの少なくとも 1 つが安全である限り、他のアルゴリズムが危険にさらされている限り、その出力を組み合わせてセキュリティを提供します。このドキュメントでは、「ハイブリッド」という用語を同じ意味で使用します。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
When the X25519MLKEM768 group is negotiated, the client's key_exchange value is the concatenation of the client's ML-KEM-768 encapsulation key and the client's X25519 ephemeral share. The size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519).
X25519MLKEM768 グループがネゴシエートされると、クライアントの key_exchange 値は、クライアントの ML-KEM-768 カプセル化キーとクライアントの X25519 一時共有を連結したものになります。クライアント共有のサイズは 1216 バイト (ML-KEM 部分では 1184 バイト、X25519 では 32 バイト) です。
Note: The group name X25519MLKEM768 does not adhere to the naming convention outlined in Section 3.2 of [RFC9954]. Specifically, the order of shares in the concatenation has been reversed. This is due to historical reasons.
注: グループ名 X25519MLKEM768 は、[RFC9954] のセクション 3.2 に概説されている命名規則に従っていません。具体的には、連結内のシェアの順序が逆になっています。これは歴史的な理由によるものです。
When the SecP256r1MLKEM768 group is negotiated, the client's key_exchange value is the concatenation of the secp256r1 ephemeral share and ML-KEM-768 encapsulation key. The ECDHE share is the serialized value of the uncompressed ECDHE point representation as defined in Section 4.3.8.2 of [RFC9846]. The size of the client share is 1249 bytes (65 bytes for the secp256r1 part and 1184 bytes for ML-KEM).
SecP256r1MLKEM768 グループがネゴシエートされると、クライアントの key_exchange 値は、secp256r1 一時共有と ML-KEM-768 カプセル化キーを連結したものになります。ECDHE シェアは、[RFC9846] のセクション 4.3.8.2 で定義されている非圧縮 ECDHE ポイント表現のシリアル化された値です。クライアント共有のサイズは 1249 バイト (secp256r1 部分の場合は 65 バイト、ML-KEM の場合は 1184 バイト) です。
When the SecP384r1MLKEM1024 group is negotiated, the client's key_exchange value is the concatenation of the secp384r1 ephemeral share and the ML-KEM-1024 encapsulation key. The ECDHE share is the serialized value of the uncompressed ECDHE point representation as defined in Section 4.3.8.2 of [RFC9846]. The size of the client share is 1665 bytes (97 bytes for the secp384r1 part and 1568 for ML-KEM).
SecP384r1MLKEM1024 グループがネゴシエートされると、クライアントの key_exchange 値は、secp384r1 一時共有と ML-KEM-1024 カプセル化キーを連結したものになります。ECDHE シェアは、[RFC9846] のセクション 4.3.8.2 で定義されている非圧縮 ECDHE ポイント表現のシリアル化された値です。クライアント共有のサイズは 1665 バイト (secp384r1 部分では 97 バイト、ML-KEM では 1568 バイト) です。
When the X25519MLKEM768 group is negotiated, the server's key_exchange value is the concatenation of an ML-KEM ciphertext returned from encapsulation to the client's encapsulation key and the server's ephemeral X25519 share. The size of the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519).
X25519MLKEM768 グループがネゴシエートされると、サーバーの key_exchange 値は、カプセル化からクライアントのカプセル化キーとサーバーの一時的な X25519 共有に返された ML-KEM 暗号文を連結したものになります。サーバー共有のサイズは 1120 バイト (ML-KEM 部分は 1088 バイト、X25519 は 32 バイト) です。
When the SecP256r1MLKEM768 group is negotiated, the server's key_exchange value is the concatenation of the server's ephemeral secp256r1 share encoded in the same way as the client share and an ML-KEM ciphertext returned from encapsulation to the client's encapsulation key. The size of the server share is 1153 bytes (1088 bytes for the ML-KEM part and 65 bytes for secp256r1).
SecP256r1MLKEM768 グループがネゴシエートされると、サーバーの key_exchange 値は、クライアント共有と同じ方法でエンコードされたサーバーの一時的な secp256r1 共有と、カプセル化からクライアントのカプセル化キーに返された ML-KEM 暗号文を連結したものになります。サーバー共有のサイズは 1153 バイト (ML-KEM 部分は 1088 バイト、secp256r1 は 65 バイト) です。
When the SecP384r1MLKEM1024 group is negotiated, the server's key_exchange value is the concatenation of the server's ephemeral secp384r1 share encoded in the same way as the client share and an ML-KEM ciphertext returned from encapsulation to the client's encapsulation key. The size of the server share is 1665 bytes (1568 bytes for the ML-KEM part and 97 bytes for secp384r1).
SecP384r1MLKEM1024 グループがネゴシエートされると、サーバーの key_exchange 値は、クライアント共有と同じ方法でエンコードされたサーバーの一時的な secp384r1 共有と、カプセル化からクライアントのカプセル化キーに返された ML-KEM 暗号文を連結したものになります。サーバー共有のサイズは 1665 バイト (ML-KEM 部分は 1568 バイト、secp384r1 は 97 バイト) です。
For all groups, the server MUST perform the encapsulation key check described in Section 7.2 of [NIST-FIPS-203] on the client's encapsulation key and abort with an illegal_parameter alert if it fails.
すべてのグループについて、サーバーはクライアントのカプセル化キーに対して [NIST-FIPS-203] のセクション 7.2 で説明されているカプセル化キーのチェックを実行し、失敗した場合はillegal_parameter アラートで中止しなければなりません (MUST)。
For all groups, the client MUST check if the ciphertext length matches the selected group and abort with an illegal_parameter alert if it fails. If ML-KEM decapsulation fails for any other reason, the connection MUST be aborted with an internal_error alert.
すべてのグループについて、クライアントは暗号文の長さが選択したグループと一致するかどうかを確認し、失敗した場合は、illegal_parameter アラートで中止しなければなりません。他の理由で ML-KEM のカプセル化解除が失敗した場合は、internal_error アラートを出して接続を中止しなければなりません。
For all groups, both client and server MUST process the ECDHE part as described in Section 4.3.8.2 of [RFC9846], including all validity checks, and abort with an illegal_parameter alert if it fails.
すべてのグループについて、クライアントとサーバーの両方は、[RFC9846] のセクション 4.3.8.2 に記載されているように、すべての有効性チェックを含む ECDHE 部分を処理し、失敗した場合は、illegal_parameter アラートで中止しなければなりません (MUST)。
For X25519MLKEM768, the shared secret is the concatenation of the ML-KEM shared secret and the X25519 shared secret. The shared secret is 64 bytes (32 bytes for each part).
X25519MLKEM768 の場合、共有秘密は ML-KEM 共有秘密と X25519 共有秘密を連結したものです。共有秘密は 64 バイト (各部分で 32 バイト) です。
For SecP256r1MLKEM768, the shared secret is the concatenation of the ECDHE and ML-KEM shared secrets. The ECDHE shared secret is the x-coordinate of the ECDHE shared secret elliptic curve point represented as an octet string as defined in Section 7.4.2 of [RFC9846]. The size of the shared secret is 64 bytes (32 bytes for each part).
SecP256r1MLKEM768 の場合、共有秘密は ECDHE 共有秘密と ML-KEM 共有秘密を連結したものです。ECDHE 共有秘密は、[RFC9846] のセクション 7.4.2 で定義されているオクテット文字列として表される ECDHE 共有秘密の楕円曲線点の x 座標です。共有秘密のサイズは 64 バイト (各部分で 32 バイト) です。
For SecP384r1MLKEM1024, the shared secret is the concatenation of the ECDHE and ML-KEM shared secrets. The ECDHE shared secret is the x-coordinate of the ECDHE shared secret elliptic curve point represented as an octet string as defined in Section 7.4.2 of [RFC9846]. The size of the shared secret is 80 bytes (48 bytes for the ECDHE part and 32 bytes for the ML-KEM part).
SecP384r1MLKEM1024 の場合、共有秘密は ECDHE 共有秘密と ML-KEM 共有秘密を連結したものです。ECDHE 共有秘密は、[RFC9846] のセクション 7.4.2 で定義されているオクテット文字列として表される ECDHE 共有秘密の楕円曲線点の x 座標です。共有秘密のサイズは 80 バイト (ECDHE 部分は 48 バイト、ML-KEM 部分は 32 バイト) です。
For all groups, both client and server MUST calculate the ECDHE part of the shared secret as described in Section 7.4.2 of [RFC9846], including the all-zero shared secret check for X25519, and abort the connection with an illegal_parameter alert if it fails.
すべてのグループについて、クライアントとサーバーの両方は、[RFC9846] のセクション 7.4.2 で説明されているように、X25519 のすべてゼロの共有秘密チェックを含む共有秘密の ECDHE 部分を計算し、失敗した場合は、illegal_parameter アラートで接続を中止しなければなりません (MUST)。
This section provides informal notes on how the hybrid key agreement mechanisms defined in this document relate to existing NIST guidance on key derivation and hybrid key establishment.
このセクションでは、この文書で定義されているハイブリッド鍵合意メカニズムが、鍵導出およびハイブリッド鍵確立に関する既存の NIST ガイダンスにどのように関連しているかについて、非公式のメモを提供します。
* *FIPS-compliance*. All groups defined in this document permit FIPS-approved key derivation as per [NIST-SP-800-56C] and [NIST-SP-800-135]. NIST Special Publication 800-56Cr2 [NIST-SP-800-56C] approves the usage of the HMAC-based Key Derivation Function (HKDF) [RFC5869] with two distinct shared secrets, with the condition that the first one is computed by a FIPS-approved key-establishment scheme. FIPS also requires a certified implementation of the scheme, which will remain more ubiquitous for secp256r1 in the coming years. For this reason, the ML-KEM shared secret is placed first in X25519MLKEM768, while the ECDHE shared secret is placed first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. This means that for SecP256r1MLKEM768 and SecP384r1MLKEM1024, the ECDHE implementation must be certified, whereas the ML-KEM implementation does not require certification. In contrast, for X25519MLKEM768, the ML-KEM implementation must be certified.
* *FIPS 準拠*。この文書で定義されているすべてのグループは、[NIST-SP-800-56C] および [NIST-SP-800-135] に従って FIPS 承認のキー導出を許可します。NIST 特別出版物 800-56Cr2 [NIST-SP-800-56C] は、2 つの異なる共有秘密を持つ HMAC ベースの鍵導出関数 (HKDF) [RFC5869] の使用を承認していますが、最初の共有秘密が FIPS 承認の鍵確立スキームによって計算されるという条件付きです。FIPS では、このスキームの認定された実装も必要としています。このスキームは、今後数年間で secp256r1 にとってさらに普及し続けるでしょう。このため、ML-KEM 共有秘密は X25519MLKEM768 の最初に配置され、ECDHE 共有秘密は SecP256r1MLKEM768 および SecP384r1MLKEM1024 の最初に配置されます。これは、SecP256r1MLKEM768 および SecP384r1MLKEM1024 では、ECDHE 実装が認定される必要があるのに対し、ML-KEM 実装は認定を必要としないことを意味します。対照的に、X25519MLKEM768 の場合、ML-KEM 実装は認定される必要があります。
* *SP800-227 compliance*. NIST Special Publication 800-227 [NIST-SP-800-227] provides general guidance on the design and use of key encapsulation mechanisms, including hybrid constructions. The key agreements defined in this document follow the principles described in Section 4.6 of [NIST-SP-800-227], which discusses the combination of post-quantum and classical key-establishment schemes and the use of approved key combiners. In particular, the shared-secret concatenation and HKDF-based derivation used by TLS 1.3 are consistent with the composite-KEM constructions and key-combiner recommendations outlined in Sections 4.6.1 and 4.6.2 of [NIST-SP-800-227]. Section 4.6.3 of [NIST-SP-800-227] further provides relevant security considerations for hybrid KEM designs underlying the approach used in this document.
* *SP800-227準拠*。NIST 特別出版物 800-227 [NIST-SP-800-227] は、ハイブリッド構造を含む主要なカプセル化メカニズムの設計と使用に関する一般的なガイダンスを提供します。この文書で定義される鍵協定は、ポスト量子鍵確立スキームと古典的鍵確立スキームの組み合わせと、承認された鍵結合器の使用について説明する [NIST-SP-800-227] のセクション 4.6 で説明されている原則に従います。特に、TLS 1.3 で使用される共有秘密の連結と HKDF ベースの導出は、[NIST-SP-800-227] のセクション 4.6.1 および 4.6.2 で概説されている複合 KEM 構造およびキー結合の推奨事項と一致しています。[NIST-SP-800-227] のセクション 4.6.3 では、この文書で使用されるアプローチの基礎となるハイブリッド KEM 設計に関連するセキュリティ上の考慮事項がさらに提供されます。
The same security considerations as those described in [RFC9954] apply to the approach used by this document. The security analysis relies crucially on the TLS 1.3 message transcript, and one cannot assume a similar hybridization is secure in other protocols.
[RFC9954] で説明されているものと同じセキュリティ上の考慮事項が、この文書で使用されるアプローチに適用されます。セキュリティ分析は TLS 1.3 メッセージ トランスクリプトに大きく依存しており、同様のハイブリッド化が他のプロトコルでも安全であると想定することはできません。
[NIST-SP-800-227] includes guidelines and requirements for implementations on using KEMs securely. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers.
[NIST-SP-800-227] には、KEM を安全に使用するための実装のガイドラインと要件が含まれています。実装者は、サイドチャネル攻撃、特にリモート攻撃者によって適用される可能性のある攻撃に耐性のある実装を使用することが推奨されます。
All groups defined in this document use and generate fixed-length public keys, ciphertexts, and shared secrets, which complies with the requirements described in Section 6 of [RFC9954].
この文書で定義されているすべてのグループは、[RFC9954] のセクション 6 で説明されている要件に準拠する、固定長の公開鍵、暗号文、および共有秘密を使用および生成します。
During ML-KEM encapsulation, encapsulation randomness m is drawn from a random bit generator and encrypted (see [NIST-FIPS-203], Algorithms 17 and 20); the client, which holds the decapsulation key, then recovers m exactly during decapsulation (see [NIST-FIPS-203], Algorithm 18). Consequently, any information m carries about the generator's other outputs is also exposed to the client.
ML-KEM カプセル化中に、カプセル化のランダム性 m がランダム ビット ジェネレーターから抽出され、暗号化されます ([NIST-FIPS-203]、アルゴリズム 17 および 20 を参照)。カプセル化解除キーを保持するクライアントは、カプセル化解除中に正確に m を回復します ([NIST-FIPS-203]、アルゴリズム 18 を参照)。その結果、ジェネレーターの他の出力に関して m が持つ情報もクライアントに公開されます。
The disclosure of the output(s) of an insecure random number generator (RNG) when used in TLS can be used in an attack to compromise the state of the insecure RNG itself as described in [DUALECTLS]. The encapsulation randomness m in ML-KEM is an additional place where RNG output is disclosed to an active attacker. Implementers should follow the RBG guidance in [NIST-FIPS-203] and the random number generation guidance in Appendix C.1 of [RFC9846]. Implementers can choose to implement mechanisms from [RFC8937] for additional protection across sessions.
TLS で使用される場合、安全でない乱数生成器 (RNG) の出力の開示は、[DUALECTLS] で説明されているように、安全でない RNG 自体の状態を侵害する攻撃に使用される可能性があります。ML-KEM のカプセル化ランダム性 m は、RNG 出力が積極的な攻撃者に公開される追加の場所です。実装者は、[NIST-FIPS-203] の RBG ガイダンスおよび [RFC9846] の付録 C.1 の乱数生成ガイダンスに従う必要があります。実装者は、セッション全体にわたる追加の保護のために [RFC8937] のメカニズムを実装することを選択できます。
In contrast, the ECDH ephemeral scalars taken from the RNG are never directly disclosed to the peer. However, any passive observer with access to a cryptographically relevant quantum computer (CRQC) can recover the scalar, which is derived directly from RNG output. Regardless, ephemeral scalars should always be generated using a cryptographically secure RNG: for secp256r1 and secp384r1 as required by [NIST-SP-800-56A], and for X25519 as described in [RFC7748]; the guidance in Appendix C.1 of [RFC9846] applies here as well.
対照的に、RNG から取得された ECDH 一時スカラーは、ピアに直接公開されることはありません。ただし、暗号関連量子コンピューター (CRQC) にアクセスできるパッシブ オブザーバーは、RNG 出力から直接得られるスカラーを復元できます。いずれにしても、エフェメラル スカラーは常に、暗号的に安全な RNG を使用して生成されるべきです。 secp256r1 および secp384r1 の場合は [NIST-SP-800-56A] で要求され、X25519 の場合は [RFC7748] で説明されています。[RFC9846] の付録 C.1 のガイダンスがここにも適用されます。
If the same insecure RNG is used by both algorithms, then a disclosure of state by one of the algorithms will also affect the security of the other algorithm.
同じ安全でない RNG が両方のアルゴリズムで使用されている場合、一方のアルゴリズムによる状態の開示は、もう一方のアルゴリズムのセキュリティにも影響します。
Per this document, IANA has registered three new entries in the "TLS Supported Groups" registry (https://www.iana.org/assignments/tls-parameters), according to the procedures in Section 6 of [RFC9847]. These identifiers are to be used with the final version of ML-KEM ratified by NIST, which is specified in [NIST-FIPS-203].
この文書に従って、IANA は [RFC9847] のセクション 6 の手順に従って、「TLS Supported Groups」レジストリ (https://www.iana.org/assignments/tls-parameters) に 3 つの新しいエントリを登録しました。これらの識別子は、[NIST-FIPS-203] で規定されている、NIST によって承認された ML-KEM の最終バージョンで使用されます。
Value:
値：
4588 (0x11EC)
4588 (0x11EC)
Description:
説明：
X25519MLKEM768
X25519MLKEM768
DTLS-OK:
DTLS-OK:
Y
Y
Recommended:
推奨：
Y
Y
Reference:
参照：
RFC 10024
RFC 10024
Comment:
コメント：
Combining X25519 ECDH with ML-KEM-768
X25519 ECDH と ML-KEM-768 の組み合わせ
Value:
値：
4587 (0x11EB)
4587 (0x11EB)
Description:
説明：
SecP256r1MLKEM768
SecP256r1MLKEM768
DTLS-OK:
DTLS-OK:
Y
Y
Recommended:
推奨：
N
N
Reference:
参照：
RFC 10024
RFC 10024
Comment:
コメント：
Combining secp256r1 ECDH with ML-KEM-768
secp256r1 ECDH と ML-KEM-768 の組み合わせ
Value:
値：
4589 (0x11ED)
4589 (0x11ED)
Description:
説明：
SecP384r1MLKEM1024
SecP384r1MLKEM1024
DTLS-OK:
DTLS-OK:
Y
Y
Recommended:
推奨：
N
N
Reference:
参照：
RFC 10024
RFC 10024
Comment:
コメント：
Combining secp384r1 ECDH with ML-KEM-1024
secp384r1 ECDH と ML-KEM-1024 の組み合わせ
Experimental code points for pre-standard versions of Kyber768 were added to the "TLS Supported Groups" registry as X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft00 (25498). This document obsoletes these entries. For both entries, IANA has modified the Recommended field to 'D', added this document as a reference, and updated the Comment field to "Pre-standards version of Kyber768. Obsoleted by RFC 10024."
Kyber768 の標準以前のバージョンの実験コード ポイントが、「TLS Supported Groups」レジストリに X25519Kyber768Draft00 (25497) および SecP256r1Kyber768Draft00 (25498) として追加されました。このドキュメントでは、これらのエントリは廃止されます。両方のエントリについて、IANA は推奨フィールドを「D」に変更し、この文書を参考資料として追加し、コメント フィールドを「Kyber768 の先行標準バージョン。RFC 10024 によって廃止されました。」に更新しました。
[NIST-FIPS-186]
NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
DOI 10.6028/NIST.FIPS.186-5, February 2023,
<https://doi.org/10.6028/NIST.FIPS.186-5>.
[NIST-FIPS-203]
NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", NIST FIPS 203, DOI 10.6028/NIST.FIPS.203,
August 2024, <https://doi.org/10.6028/NIST.FIPS.203>.
[NIST-SP-800-56C]
Barker, E., Chen, L., and R. Davis, "Recommendation for
Key-Derivation Methods in Key-Establishment Schemes",
National Institute of Standards and Technology, NIST
SP 800-56Cr2, DOI 10.6028/nist.sp.800-56cr2, August 2020,
<https://doi.org/10.6028/nist.sp.800-56cr2>.
[NIST-SP-800-135]
Dang, Q., "Recommendation for Existing Application-
Specific Key Derivation Functions", National Institute of
Standards and Technology, NIST SP 800-135r1,
DOI 10.6028/nist.sp.800-135r1, December 2011,
<https://doi.org/10.6028/nist.sp.800-135r1>.
[NIST-SP-800-227]
Alagic, G., Barker, E., Chen, L., Moody, D., Robinson, A.,
Silberg, H., and N. Waller, "Recommendations for Key-
Encapsulation Mechanisms", National Institute of Standards
and Technology, NIST SP 800-227,
DOI 10.6028/nist.sp.800-227, September 2025,
<https://doi.org/10.6028/nist.sp.800-227>.
[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>.
[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>.
[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>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[RFC9954] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid Key
Exchange in TLS 1.3", RFC 9954, DOI 10.17487/RFC9954, July
2026, <https://www.rfc-editor.org/info/rfc9954>.
[DUALECTLS]
Checkoway, S., Fredrikson, M., Niederhagen, R.,
Everspaugh, A., Green, M., Lange, T., Ristenpart, T.,
Bernstein, D. J., Maskiewicz, J., and H. Shacham, "On the
Practical Exploitability of Dual EC in TLS
Implementations", 23rd USENIX Security Symposium (USENIX
Security 14), 2014,
<https://www.usenix.org/system/files/conference/
usenixsecurity14/sec14-paper-checkoway.pdf>.
[NIST-SP-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography", National
Institute of Standards and Technology, NIST SP 800-56Ar3,
DOI 10.6028/nist.sp.800-56ar3, April 2018,
<https://doi.org/10.6028/nist.sp.800-56ar3>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC8937] Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N.,
and C. Wood, "Randomness Improvements for Security
Protocols", RFC 8937, DOI 10.17487/RFC8937, October 2020,
<https://www.rfc-editor.org/info/rfc8937>.
[RFC9794] Driscoll, F., Parsons, M., and B. Hale, "Terminology for
Post-Quantum Traditional Hybrid Schemes", RFC 9794,
DOI 10.17487/RFC9794, June 2025,
<https://www.rfc-editor.org/info/rfc9794>.
[RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
<https://www.rfc-editor.org/info/rfc9847>.
Krzysztof Kwiatkowski
PQShield
Email: kris@amongbytes.com
Panos Kampanakis
AWS
Email: kpanos@amazon.com
Bas Westerbaan
Cloudflare
Email: bas@cloudflare.com
Douglas Stebila
University of Waterloo
Email: dstebila@uwaterloo.ca