Alignment with the newest version of draft-ietf-tls-hybrid-design

draft-ietf-tls-ecdhe-mlkem.md

@@ -47,11 +47,10 @@ 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
   tlsiana: I-D.ietf-tls-rfc8447bis
   HKDF: DOI.10.17487/RFC5869
@@ -65,56 +64,52 @@ 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
-most 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 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 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). The goal of this group is to provide support for high
-security environments that require use of FIPS-approved mechanisms.
+* 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}}.
 
-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
 
 {::boilerplate bcp14-tagged}
 
 # 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 +118,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 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).
 
-### 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 +143,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 +155,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 +179,18 @@ 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 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. 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
 
 The same security considerations as those described in {{hybrid}} apply to the approach used by this document.
@@ -193,11 +200,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 +274,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.
+  * The Construction section has been removed.
+
+* 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