Add P-384 combined with ML-KEM-1024 (#22)

draft-kwiatkowski-tls-ecdhe-mlkem.md

@@ -63,7 +63,8 @@ informative:
          ANSI: ANS X9.62-2005
 --- abstract
 
-This draft defines two hybrid key agreements for TLS 1.3: X25519MLKEM768 and SecP256r1MLKEM768, which combine
+This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768,
+SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine
 a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE).
 
 --- middle
@@ -74,9 +75,10 @@ a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE).
 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 two new supported groups for hybrid post-quantum key
-agreements in TLS 1.3: X25519MLKEM768 and SecP256r1MLKEM768. Both combine ML-KEM-768 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.
@@ -85,22 +87,26 @@ The second one uses secp256r1 (NIST P-256) {{ECDSA}} {{?DSS=DOI.10.6028/NIST.SP.
 goal of this group is to support a use case that requires both shared secrets to be generated by
 FIPS-approved mechanisms.
 
-Both constructions aim to provide a FIPS-approved key-establishment scheme (as per {{SP56C}}).
+The third one uses secp384r1 (NIST P-384) {{ECDSA}} {{?DSS=DOI.10.6028/NIST.SP.800-186}}.
+The goal of this group is to provide support for high security environments
+that require use of FIPS-approved mechanisms.
+
+All constructions aim to provide a FIPS-approved key-establishment scheme (as per {{SP56C}}).
 
 # Conventions and Definitions
 
 {::boilerplate bcp14-tagged}
 
 # Negotiated Groups
 
-Both groups enable the derivation of TLS session keys using FIPS-approved schemes. NIST's
+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-768 shared secret first in X25519MLKEM768,
-and the secp256r1 shared secret first in SecP256r1MLKEM768.
+For this reason we put the ML-KEM shared secret first in X25519MLKEM768,
+and the ECDH shared secret first in SecP256r1MLKEM768 and SecP384r1MLKEM1024.
 
 ## Construction
 
@@ -117,6 +123,12 @@ The ECDHE share is the serialized value of the uncompressed ECDH point represent
 defined  in Section 4.2.8.2 of {{!RFC8446}}. The size of the client share is 1249 bytes
 (65 bytes for the secp256r1 part and 1184 bytes for ML-KEM).
 
+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
+client share is 1665 bytes (97 bytes for the secp384r1 and the 1568 for the ML-KEM).
+
 ### Server share
 
 When the X25519MLKEM768 group is negotiated, the server's key exchange
@@ -130,7 +142,14 @@ in the same way as the client share and an ML-KEM ciphertext returned from encap
 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).
 
-For both groups, the server MUST perform the encapsulation key check
+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)
+
+For all groups, the server MUST perform the encapsulation key check
 described in Section 7.2 of {{FIPS203}} on the client's encapsulation
 key, and abort with an illegal_parameter alert if it fails.
 
@@ -146,6 +165,13 @@ shared secret elliptic curve point represented as an octet string as
 defined in Section 7.4.2 of {{!RFC8446}}.
 The size of the shared secret is 64 bytes (32 bytes for each part).
 
+For SecP384r1MLKEM1024, the shared secret is the concatenation of the
+ECDHE and ML-KEM shared secret. The ECDHE shared secret is the x-coordinate of the ECDH
+shared secret elliptic curve point represented as an octet string as
+defined in Section 7.4.2 of {{!RFC8446}}.
+The size of the shared secret is 80 bytes (48 bytes for the ECDH part and
+32 bytes for the ML-KEM part).
+
 # Security Considerations
 
 The same security considerations as those described in {{hybrid}} apply to the approach used by this document.
@@ -157,7 +183,7 @@ especially those that can be applied by remote attackers.
 
 # IANA Considerations
 
-This document requests/registers two new entries to the TLS Supported Groups registry, according
+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}}.
 
@@ -201,6 +227,27 @@ ratified by NIST, version of ML-KEM which is specified in {{FIPS203}}.
  Comment:
  : Combining X25519 ECDH with ML-KEM-768
 
+## SecP384r1MLKEM1024
+
+ Value:
+ : 4589 (0x11ED)
+
+ Description:
+ : SecP384r1MLKEM1024
+
+ DTLS-OK:
+ : Y
+
+ Recommended:
+ : N
+
+ Reference:
+ : This document
+
+ Comment:
+ : Combining secp384r1 ECDH with ML-KEM-1024
+
+
 ## Obsoleted Supported Groups
 
 This document obsoletes 25497 and 25498 in the TLS Supported Groups registry.