From 7675716f84f7d438e7dbc243f9d4dd22d0abf565 Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Mon, 22 Sep 2025 00:09:23 +0100 Subject: [PATCH 1/9] Alignment with the newest version of draft-ietf-tls-hybrid-design * Added new section called Discussion and moved FIPS-compliance and Failures text there. * Removed Construction section. * Various cosmetic changes --- draft-ietf-tls-ecdhe-mlkem.md | 93 +++++++++++++++++++++-------------- 1 file changed, 56 insertions(+), 37 deletions(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index 2130c73..2ddcbaa 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -47,9 +47,9 @@ author: normative: rfc7748: - FIPS203: DOI.10.6028/NIST.FIPS.203 - SP56C: DOI.10.6028/NIST.SP.800-56Cr2 - + NIST-FIPS-203: DOI.10.6028/NIST.FIPS.203 + NIST-SP-800-56C: DOI.10.6028/NIST.SP.800-56Cr2 + NIST-SP-800-135: DOI.10.6028/NIST.SP.800-135r1 informative: xyber: I-D.tls-westerbaan-xyber768d00-03 hybrid: I-D.ietf-tls-hybrid-design @@ -65,27 +65,37 @@ a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE). # Introduction +The {{hybrid}} document 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. + +This document applies the framework to ML-KEM, a key encapsulation mechanism defined in {{NIST-FIPS-203}}, +and specifies code points for the hybrid groups. + ## Motivation -ML-KEM is a key encapsulation method (KEM) defined in the {{FIPS203}}. It is designed to -withstand cryptanalytic attacks from quantum computers. -This document introduces three new supported groups for hybrid post-quantum key -agreements in TLS 1.3: the X25519MLKEM768, SecP256r1MLKEM768, -and SecP384r1MLKEM1024 which combine ML-KEM with ECDH -in the manner of {{hybrid}}. +This document introduces three new supported groups for hybrid post-quantum key agreements in TLS 1.3: the X25519MLKEM768, +SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine ML-KEM with ECDH in the manner of {{hybrid}}. -The first one uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, the +* The first one uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, the most widely deployed PQ/T hybrid combiner for TLS v1.3 deployed in 2024. -The second one uses secp256r1 (NIST P-256). The goal of this group is to support a use case +* The second one uses secp256r1 (NIST P-256). The goal of this group is to support a use case that requires both shared secrets to be generated by FIPS-approved mechanisms. -The third one uses secp384r1 (NIST P-384). The goal of this group is to provide support for high +* The third one uses secp384r1 (NIST P-384). The goal of this group is to provide support for high security environments that require use of FIPS-approved mechanisms. Key establishment using NIST curves is outlined in Section 6.1.1.2 of {{!KEYAGREEMENT=DOI.10.6028/NIST.SP.800-56Ar3}}. -All constructions aim to provide a FIPS-approved key-establishment scheme (as per {{SP56C}}). +## Terminology + +The {{hybrid}} document 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, ECDH using Curve25519, P-256, or +P-384 is considered traditional, while ML-KEM is considered next-generation. + +The {{hybrid}} document defines a "hybrid" key exchange as one that combines a traditional key exchange with a next-generation key +exchange. This document uses the term "hybrid" in the same way. # Conventions and Definitions @@ -93,28 +103,17 @@ All constructions aim to provide a FIPS-approved key-establishment scheme (as pe # Negotiated Groups -All groups enable the derivation of TLS session keys using FIPS-approved schemes. NIST's -special publication 800-56Cr2 {{SP56C}} approves the usage of HKDF -{{HKDF}} 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 ubiqutous for secp256r1 in the coming years. - -For this reason we put the ML-KEM shared secret first in X25519MLKEM768, -and the ECDH shared secret first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. - -Note: The group name X25519MLKEM768 does not adhere to the naming convention outlined in -{{Section 3.2 of hybrid}}. Specifically, the order of shares in the concatenation has been -reversed. This is due to historical reasons. - -## Construction - -### Client share +## Client share 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). +Note: The group name X25519MLKEM768 does not adhere to the naming convention outlined in +{{Section 3.2 of hybrid}}. Specifically, the order of shares in the concatenation has been +reversed. This is due to historical reasons. + 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 ECDH point representation as @@ -123,11 +122,11 @@ defined in {{Section 4.2.8.2 of !RFC8446}}. The size of the client share is 124 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 ECDH share is serialised value of the uncompressed ECDH point -represenation as defined in {{Section 4.2.8.2 of !RFC8446}}. The size of the +encapsulation key. The ECDH share is serialized value of the uncompressed ECDH point +representation as defined in {{Section 4.2.8.2 of !RFC8446}}. The size of the client share is 1665 bytes (97 bytes for the secp384r1 and the 1568 for the ML-KEM). -### Server share +## Server share When the X25519MLKEM768 group is negotiated, the server's key exchange value is the concatenation of an ML-KEM ciphertext returned from encapsulation @@ -148,7 +147,7 @@ share is 1665 bytes (1568 bytes for the ML-KEM part and 97 bytes for secp384r1) For all groups, the server MUST perform the encapsulation key check -described in Section 7.2 of {{FIPS203}} on the client's encapsulation +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. For all groups, the client MUST check if the ciphertext length matches @@ -160,7 +159,7 @@ For all groups, both client and server MUST process the ECDH part as described in {{Section 4.2.8.2 of !RFC8446}}, including all validity checks, and abort with an illegal_parameter alert if it fails. -### Shared secret +## Shared secret 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 @@ -184,6 +183,19 @@ shared secret as described in {{Section 7.4.2 of !RFC8446}}, including the all-zero shared secret check for X25519, and abort the connection with an illegal_parameter alert if it fails. +# Discussion + +**FIPS-compliance**. All groups permit FIPS-approved key derivation as per {{NIST-SP-800-56C}} +and {{NIST-SP-800-135}}. NIST's special publication 800-56Cr2 {{NIST-SP-800-56C}} approves the +usage of HKDF {{HKDF}} 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 we put the ML-KEM shared secret first in X25519MLKEM768, and the ECDH shared secret +first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. + +**Failures**. We note that ML-KEM algorithm has non-zero probability of encapsulation and decapsulation failures. Those +failures MAY be handled by clients in a way described in {{Section 4 of hybrid}}. + # Security Considerations The same security considerations as those described in {{hybrid}} apply to the approach used by this document. @@ -193,11 +205,14 @@ hybridisation is secure in other protocols. Implementers are encouraged to use implementations resistant to side-channel attacks, especially those that can be applied by remote attackers. +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 hybrid}}. + # IANA Considerations This document requests/registers three new entries to the TLS Supported Groups registry, according to the procedures in {{Section 6 of tlsiana}}. These identifiers are to be used with the final, -ratified by NIST, version of ML-KEM which is specified in {{FIPS203}}. +ratified by NIST, version of ML-KEM which is specified in {{NIST-FIPS-203}}. ## SecP256r1MLKEM768 @@ -264,13 +279,17 @@ ratified by NIST, version of ML-KEM which is specified in {{FIPS203}}. ## Obsoleted Supported Groups -This document obsoletes 25497 and 25498 in the TLS Supported Groups registry. +This document obsoletes X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft00 (25498) in the TLS Supported Groups registry. --- back # Change log - * draft-ietf-tls-ecdhe-mlkem-01: + * Alignment with the final version of {{hybrid}} + * Added new section called Discussion and moved FIPS-compliance and Failures text there. + * Removed Construction section. + +* draft-ietf-tls-ecdhe-mlkem-00: * Change a name of the draft, following adoption by TLS WG * Fixes references to the to NIST ECC CDH From 08411f221c82c5c02967c120e7cc575b61372484 Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Wed, 24 Sep 2025 00:07:24 +0100 Subject: [PATCH 2/9] Update draft-ietf-tls-ecdhe-mlkem.md Co-authored-by: Deirdre Connolly --- draft-ietf-tls-ecdhe-mlkem.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index 2ddcbaa..7b4af3c 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -193,8 +193,7 @@ implementation of the scheme, which will remain more ubiquitous for secp256r1 in this reason we put the ML-KEM shared secret first in X25519MLKEM768, and the ECDH shared secret first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. -**Failures**. We note that ML-KEM algorithm has non-zero probability of encapsulation and decapsulation failures. Those -failures MAY be handled by clients in a way described in {{Section 4 of hybrid}}. +**Failures**. Any hybrid key establishment failures MAY be handled by clients in a way described in {{Section 4 of hybrid}}. # Security Considerations From 0614550dc088903f6fde5af150ec971f2f0031f7 Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Wed, 24 Sep 2025 00:17:07 +0100 Subject: [PATCH 3/9] Address comments from the review --- draft-ietf-tls-ecdhe-mlkem.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index 7b4af3c..3fea064 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -77,14 +77,11 @@ and specifies code points for the hybrid groups. This document introduces three new supported groups for hybrid post-quantum key agreements in TLS 1.3: the X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine ML-KEM with ECDH in the manner of {{hybrid}}. -* The first one uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, the -most widely deployed PQ/T hybrid combiner for TLS v1.3 deployed in 2024. +* The first one uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, a widely deployed PQ/T hybrid combiner for TLS v1.3 deployed in 2024. -* The second one uses secp256r1 (NIST P-256). The goal of this group is to support a use case -that requires both shared secrets to be generated by FIPS-approved mechanisms. +* The second one uses secp256r1 (NIST P-256). This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms. -* The third one uses secp384r1 (NIST P-384). The goal of this group is to provide support for high -security environments that require use of FIPS-approved mechanisms. +* The third one uses secp384r1 (NIST P-384). This group can be used in high security environments that require FIPS-approved mechanisms at conservative security levels. Key establishment using NIST curves is outlined in Section 6.1.1.2 of {{!KEYAGREEMENT=DOI.10.6028/NIST.SP.800-56Ar3}}. From 71870e182d38f4bbe8d32cdc28198150527f5a25 Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Wed, 24 Sep 2025 00:39:10 +0100 Subject: [PATCH 4/9] Update draft-ietf-tls-ecdhe-mlkem.md Co-authored-by: Eric Rescorla --- draft-ietf-tls-ecdhe-mlkem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index 3fea064..117521d 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -119,7 +119,7 @@ defined in {{Section 4.2.8.2 of !RFC8446}}. The size of the client share is 124 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 ECDH share is serialized value of the uncompressed ECDH point +encapsulation key. The ECDH share is the serialized value of the uncompressed ECDH point representation as defined in {{Section 4.2.8.2 of !RFC8446}}. The size of the client share is 1665 bytes (97 bytes for the secp384r1 and the 1568 for the ML-KEM). From bf8fbf2bd218b0fa63cbd633abdb831c724b320b Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Wed, 24 Sep 2025 00:51:39 +0100 Subject: [PATCH 5/9] Address review comments --- draft-ietf-tls-ecdhe-mlkem.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index 117521d..b4529fe 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -77,11 +77,11 @@ and specifies code points for the hybrid groups. This document introduces three new supported groups for hybrid post-quantum key agreements in TLS 1.3: the X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine ML-KEM with ECDH in the manner of {{hybrid}}. -* The first one uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, a widely deployed PQ/T hybrid combiner for TLS v1.3 deployed in 2024. +* The first group uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, a widely deployed PQ/T hybrid combiner for TLS v1.3 deployed in 2024. -* The second one uses secp256r1 (NIST P-256). This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms. +* The second group uses secp256r1 (NIST P-256). This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms. -* The third one uses secp384r1 (NIST P-384). This group can be used in high security environments that require FIPS-approved mechanisms at conservative security levels. +* The third group uses secp384r1 (NIST P-384). This group can be used in high security environments that require FIPS-approved mechanisms at conservative security levels. Key establishment using NIST curves is outlined in Section 6.1.1.2 of {{!KEYAGREEMENT=DOI.10.6028/NIST.SP.800-56Ar3}}. @@ -182,15 +182,15 @@ illegal_parameter alert if it fails. # Discussion -**FIPS-compliance**. All groups permit FIPS-approved key derivation as per {{NIST-SP-800-56C}} +**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's special publication 800-56Cr2 {{NIST-SP-800-56C}} approves the usage of HKDF {{HKDF}} 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 we put the ML-KEM shared secret first in X25519MLKEM768, and the ECDH shared secret -first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. - -**Failures**. Any hybrid key establishment failures MAY be handled by clients in a way described in {{Section 4 of hybrid}}. +first in SecP256r1MLKEM768 and SecP384r1MLKEM1024. This means that for SecP256r1MLKEM768 and SecP384r1MLKEM1024, +the ECDH implementation must be certified whereas the ML-KEM implementation does not require certification. In +contrast, for X25519MLKEM768, the ML-KEM implementation must be certified. # Security Considerations From de9fa03e4966a57ff9bc8c9bda8fa53614b2009c Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Wed, 24 Sep 2025 09:53:00 +0100 Subject: [PATCH 6/9] Address comment from the review --- draft-ietf-tls-ecdhe-mlkem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index b4529fe..a832608 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -283,7 +283,7 @@ This document obsoletes X25519Kyber768Draft00 (25497) and SecP256r1Kyber768Draft * draft-ietf-tls-ecdhe-mlkem-01: * Alignment with the final version of {{hybrid}} * Added new section called Discussion and moved FIPS-compliance and Failures text there. - * Removed Construction section. + * The Construction section has been removed. * draft-ietf-tls-ecdhe-mlkem-00: * Change a name of the draft, following adoption by TLS WG From a8c6271d17404824ececc58156ef8349c09c16f8 Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Wed, 24 Sep 2025 15:08:15 +0100 Subject: [PATCH 7/9] Address Bas's comment --- draft-ietf-tls-ecdhe-mlkem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index a832608..8cd9d7a 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -81,7 +81,7 @@ SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine ML-KEM with ECDH in the * The second group uses secp256r1 (NIST P-256). This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms. -* The third group uses secp384r1 (NIST P-384). This group can be used in high security environments that require FIPS-approved mechanisms at conservative security levels. +* The third group uses secp384r1 (NIST P-384). This group is intended for high-security environments that require FIPS-approved mechanisms with an increased security margin. Key establishment using NIST curves is outlined in Section 6.1.1.2 of {{!KEYAGREEMENT=DOI.10.6028/NIST.SP.800-56Ar3}}. From 8205bdc605cc92450288e75a1a0f04963175848b Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Thu, 25 Sep 2025 16:59:26 +0100 Subject: [PATCH 8/9] Align with comment from ekr and Alicja --- draft-ietf-tls-ecdhe-mlkem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index 8cd9d7a..37ebf9c 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -77,7 +77,7 @@ and specifies code points for the hybrid groups. This document introduces three new supported groups for hybrid post-quantum key agreements in TLS 1.3: the X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine ML-KEM with ECDH in the manner of {{hybrid}}. -* The first group uses X25519 {{rfc7748}} and is an update to X25519Kyber768Draft00 {{xyber}}, a widely deployed PQ/T hybrid combiner for TLS v1.3 deployed in 2024. +* The first one uses X25519 {{rfc7748}}, is widely deployed, and often serves as the most practical choice for a single PQ/T hybrid combiner in TLS 1.3. * The second group uses secp256r1 (NIST P-256). This group supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms. From 231772db76dc9d93e9ddc87c3e7b426dd03cff7d Mon Sep 17 00:00:00 2001 From: Kris Kwiatkowski Date: Thu, 25 Sep 2025 17:00:35 +0100 Subject: [PATCH 9/9] Remove reference to xyber Text has no references to Xyber anymore, hence I assume it can be removed. --- draft-ietf-tls-ecdhe-mlkem.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-tls-ecdhe-mlkem.md b/draft-ietf-tls-ecdhe-mlkem.md index 37ebf9c..de8d5a5 100644 --- a/draft-ietf-tls-ecdhe-mlkem.md +++ b/draft-ietf-tls-ecdhe-mlkem.md @@ -51,7 +51,6 @@ normative: NIST-SP-800-56C: DOI.10.6028/NIST.SP.800-56Cr2 NIST-SP-800-135: DOI.10.6028/NIST.SP.800-135r1 informative: - xyber: I-D.tls-westerbaan-xyber768d00-03 hybrid: I-D.ietf-tls-hybrid-design tlsiana: I-D.ietf-tls-rfc8447bis HKDF: DOI.10.17487/RFC5869