diff --git a/draft-kwiatkowski-tls-ecdhe-mlkem.md b/draft-kwiatkowski-tls-ecdhe-mlkem.md index f7075bb..5ea58f7 100644 --- a/draft-kwiatkowski-tls-ecdhe-mlkem.md +++ b/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,7 +87,11 @@ 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 @@ -93,14 +99,14 @@ Both constructions aim to provide a FIPS-approved key-establishment scheme (as p # 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.