From d0d81ec435d881e2dbe466466726a04ae2f2c51b Mon Sep 17 00:00:00 2001 From: ID Bot Date: Wed, 25 Dec 2024 06:03:23 +0000 Subject: [PATCH] Script updating gh-pages from f78755b. [ci skip] --- .../draft-kwiatkowski-tls-ecdhe-mlkem.html | 1722 +++++++++++++++++ .../draft-kwiatkowski-tls-ecdhe-mlkem.txt | 424 ++++ .../index.html | 45 + index.html | 8 + 4 files changed, 2199 insertions(+) create mode 100644 draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.html create mode 100644 draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.txt create mode 100644 draft-kwiatkowski-tls-ecdhe-mlkem-03/index.html diff --git a/draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.html b/draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.html new file mode 100644 index 0000000..0d87fcb --- /dev/null +++ b/draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.html @@ -0,0 +1,1722 @@ + + + + + + +Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Internet-DraftECDHE-MLKEMDecember 2024
Kwiatkowski, et al.Expires 28 June 2025[Page]
+
+
+
+
Workgroup:
+
Transport Layer Security
+
Internet-Draft:
+
draft-kwiatkowski-tls-ecdhe-mlkem-latest
+
Published:
+
+ +
+
Intended Status:
+
Informational
+
Expires:
+
+
Authors:
+
+
+
K. Kwiatkowski
+
PQShield
+
+
+
P. Kampanakis
+
AWS
+
+
+
B. E. Westerbaan
+
Cloudflare
+
+
+
D. Stebila
+
University of Waterloo
+
+
+
+
+

Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

+
+

Abstract

+

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).

+
+
+

+About This Document +

+

This note is to be removed before publishing as an RFC.

+

+ The latest revision of this draft can be found at https://post-quantum-cryptography.github.io/draft-kwiatkowski-tls-ecdhe-mlkem/. + Status information for this document may be found at https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/.

+

+ Discussion of this document takes place on the + Transport Layer Security Working Group mailing list (mailto:tls@ietf.org), + which is archived at https://mailarchive.ietf.org/arch/browse/tls/. + Subscribe at https://www.ietf.org/mailman/listinfo/tls/.

+

Source for this draft and an issue tracker can be found at + https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem.

+
+
+
+

+Status of This Memo +

+

+ This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79.

+

+ Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF). Note that other groups may also distribute working + documents as Internet-Drafts. The list of current Internet-Drafts is + at https://datatracker.ietf.org/drafts/current/.

+

+ Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress."

+

+ This Internet-Draft will expire on 28 June 2025.

+
+
+ +
+
+ ▲

+Table of Contents +

+ +
+
+
+
+

+1. Introduction +

+
+
+

+1.1. 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].

+

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) [ECDSA] [DSS]. 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) [ECDSA] [DSS]. +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]).

+
+
+
+
+
+
+

+2. Conventions and Definitions +

+

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.

+
+
+
+
+

+3. 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.

+
+
+

+3.1. Construction +

+
+
+

+3.1.1. 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).

+

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 +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).

+
+
+
+
+

+3.1.2. 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 +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).

+

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).

+

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.

+

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.

+

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.

+
+
+
+
+

+3.1.3. 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 +(32 bytes for each part).

+

For SecP256r1MLKEM768, 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 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).

+

For all groups, both client and server MUST calculate the ECDH part of the +shared secret as described in Section 7.4.2 of [RFC8446], including +the shared secret check as described in Section 5.7.1.2 of [SP56A] +or the all-zero shared secret check (depending on the curve), and abort the +connection with an illegal_parameter alert if it fails.

+
+
+
+
+
+
+
+
+

+4. Security Considerations +

+

The same security considerations as those described in [hybrid] 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 +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.

+
+
+
+
+

+5. 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].

+
+
+

+5.1. SecP256r1MLKEM768 +

+
+
Value:
+
+

4587 (0x11EB)

+
+
+
Description:
+
+

SecP256r1MLKEM768

+
+
+
DTLS-OK:
+
+

Y

+
+
+
Recommended:
+
+

N

+
+
+
Reference:
+
+

This document

+
+
+
Comment:
+
+

Combining secp256r1 ECDH with ML-KEM-768

+
+
+
+
+
+
+
+

+5.2. X25519MLKEM768 +

+
+
Value:
+
+

4588 (0x11EC)

+
+
+
Description:
+
+

X25519MLKEM768

+
+
+
DTLS-OK:
+
+

Y

+
+
+
Recommended:
+
+

N

+
+
+
Reference:
+
+

This document

+
+
+
Comment:
+
+

Combining X25519 ECDH with ML-KEM-768

+
+
+
+
+
+
+
+

+5.3. SecP384r1MLKEM1024 +

+
+
Value:
+
+

4589 (0x11ED)

+
+
+
Description:
+
+

SecP384r1MLKEM1024

+
+
+
DTLS-OK:
+
+

Y

+
+
+
Recommended:
+
+

N

+
+
+
Reference:
+
+

This document

+
+
+
Comment:
+
+

Combining secp384r1 ECDH with ML-KEM-1024

+
+
+
+
+
+
+
+

+5.4. Obsoleted Supported Groups +

+

This document obsoletes 25497 and 25498 in the TLS Supported Groups registry.

+
+
+
+
+
+
+

+6. References +

+
+
+

+6.1. Normative References +

+
+
[FIPS203]
+
+"Module-lattice-based key-encapsulation mechanism standard", National Institute of Standards and Technology (U.S.), DOI 10.6028/nist.fips.203, , <https://doi.org/10.6028/nist.fips.203>.
+
+
[RFC2119]
+
+Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
+
+
[rfc7748]
+
+Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, , <https://www.rfc-editor.org/rfc/rfc7748>.
+
+
[RFC8174]
+
+Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
+
+
[RFC8446]
+
+Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/rfc/rfc8446>.
+
+
[SP56A]
+
+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, DOI 10.6028/nist.sp.800-56ar3, , <https://doi.org/10.6028/nist.sp.800-56ar3>.
+
+
[SP56C]
+
+Barker, E., Chen, L., and R. Davis, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-56cr2, , <https://doi.org/10.6028/nist.sp.800-56cr2>.
+
+
+
+
+
+
+

+6.2. Informative References +

+
+
[DSS]
+
+Chen, L., Moody, D., Regenscheid, A., Robinson, A., and K. Randall, "Recommendations for Discrete Logarithm-based Cryptography:: Elliptic Curve Domain Parameters", National Institute of Standards and Technology, DOI 10.6028/nist.sp.800-186, , <https://doi.org/10.6028/nist.sp.800-186>.
+
+
[ECDSA]
+
+American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI ANS X9.62-2005, .
+
+
[HKDF]
+
+Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC Editor, DOI 10.17487/rfc5869, , <https://doi.org/10.17487/rfc5869>.
+
+
[hybrid]
+
+Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key exchange in TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-hybrid-design-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-11>.
+
+
[tlsiana]
+
+Salowey, J. A. and S. Turner, "IANA Registry Updates for TLS and DTLS", Work in Progress, Internet-Draft, draft-ietf-tls-rfc8447bis-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8447bis-10>.
+
+
[xyber]
+
+Westerbaan, B. and D. Stebila, "X25519Kyber768Draft00 hybrid post-quantum key agreement", Work in Progress, Internet-Draft, draft-tls-westerbaan-xyber768d00-03, , <https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-03>.
+
+
+
+
+
+
+
+
+

+Appendix A. Change log +

+
    +
  • +

    draft-kwiatkowski-tls-ecdhe-mlkem-03:

    +
      +
    • +

      Adds P-384 combined with ML-KEM-1024

      +
      • +
    • +

      Adds text that describes error-handling and outlines how the client and server must ensure the integrity of the key exchange process.

      +
      • +
    • +

      Adds note on the incompatibility of the codepoint name X25519MLKEM768 with [hybrid].

      +
      • +
    • +

      Various cosmetic changes.

      +
      • +
    +
    • +
  • +

    draft-kwiatkowski-tls-ecdhe-mlkem-02:

    +
      +
    • +

      Adds section that mentions supported groups that this document obsoletes.

      +
      • +
    • +

      Fix a reference to encapsulation in the FIPS 203.

      +
      • +
    +
    • +
  • +

    draft-kwiatkowski-tls-ecdhe-mlkem-01:

    +
      +
    • +

      Add X25519MLKEM768

      +
      • +
    +
    • +
  • +

    draft-kwiatkowski-tls-ecdhe-mlkem-00:

    +
      +
    • +

      Change Kyber name to ML-KEM

      +
      • +
    • +

      Swap reference to I-D.cfrg-schwabe-kyber with FIPS-203

      +
      • +
    • +

      Change codepoint. New value is equal to old value + 1.

      +
      • +
    +
    • +
  • +

    draft-kwiatkowski-tls-ecdhe-kyber-01: Fix size of key shares generated by the client and the server

    +
    • +
  • +

    draft-kwiatkowski-tls-ecdhe-kyber-00: updates following IANA review

    +
    • +
+
+
+
+
+

+Authors' Addresses +

+
+
Kris Kwiatkowski
+
PQShield
+ +
+
+
Panos Kampanakis
+
AWS
+ +
+
+
Bas Westerbaan
+
Cloudflare
+ +
+
+
Douglas Stebila
+
University of Waterloo
+ +
+
+
+ + + diff --git a/draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.txt b/draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.txt new file mode 100644 index 0000000..85ed530 --- /dev/null +++ b/draft-kwiatkowski-tls-ecdhe-mlkem-03/draft-kwiatkowski-tls-ecdhe-mlkem.txt @@ -0,0 +1,424 @@ + + + + +Transport Layer Security K. Kwiatkowski +Internet-Draft PQShield +Intended status: Informational P. Kampanakis +Expires: 28 June 2025 AWS + B. E. Westerbaan + Cloudflare + D. Stebila + University of Waterloo + 25 December 2024 + + + Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 + draft-kwiatkowski-tls-ecdhe-mlkem-latest + +Abstract + + 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). + +About This Document + + This note is to be removed before publishing as an RFC. + + The latest revision of this draft can be found at https://post- + quantum-cryptography.github.io/draft-kwiatkowski-tls-ecdhe-mlkem/. + Status information for this document may be found at + https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/. + + Discussion of this document takes place on the Transport Layer + Security Working Group mailing list (mailto:tls@ietf.org), which is + archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe + at https://www.ietf.org/mailman/listinfo/tls/. + + Source for this draft and an issue tracker can be found at + https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls- + ecdhe-mlkem. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 28 June 2025. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +Table of Contents + + 1. Introduction + 1.1. Motivation + 2. Conventions and Definitions + 3. Negotiated Groups + 3.1. Construction + 3.1.1. Client share + 3.1.2. Server share + 3.1.3. Shared secret + 4. Security Considerations + 5. IANA Considerations + 5.1. SecP256r1MLKEM768 + 5.2. X25519MLKEM768 + 5.3. SecP384r1MLKEM1024 + 5.4. Obsoleted Supported Groups + 6. References + 6.1. Normative References + 6.2. Informative References + Appendix A. Change log + Authors' Addresses + +1. Introduction + +1.1. 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]. + + 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) [ECDSA] [DSS]. 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) [ECDSA] [DSS]. 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]). + +2. Conventions and Definitions + + 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. + +3. 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. + +3.1. Construction + +3.1.1. 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). + + 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 + 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). + +3.1.2. 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 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). + + 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). + + 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. + + 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. + + 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. + +3.1.3. 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 (32 bytes for each part). + + For SecP256r1MLKEM768, 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 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). + + For all groups, both client and server MUST calculate the ECDH part + of the shared secret as described in Section 7.4.2 of [RFC8446], + including the shared secret check as described in Section 5.7.1.2 of + [SP56A] or the all-zero shared secret check (depending on the curve), + and abort the connection with an illegal_parameter alert if it fails. + +4. Security Considerations + + The same security considerations as those described in [hybrid] 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 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. + +5. 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]. + +5.1. SecP256r1MLKEM768 + + Value: 4587 (0x11EB) + Description: SecP256r1MLKEM768 + DTLS-OK: Y + Recommended: N + Reference: This document + Comment: Combining secp256r1 ECDH with ML-KEM-768 + +5.2. X25519MLKEM768 + + Value: 4588 (0x11EC) + Description: X25519MLKEM768 + DTLS-OK: Y + Recommended: N + Reference: This document + Comment: Combining X25519 ECDH with ML-KEM-768 + +5.3. SecP384r1MLKEM1024 + + Value: 4589 (0x11ED) + Description: SecP384r1MLKEM1024 + DTLS-OK: Y + Recommended: N + Reference: This document + Comment: Combining secp384r1 ECDH with ML-KEM-1024 + +5.4. Obsoleted Supported Groups + + This document obsoletes 25497 and 25498 in the TLS Supported Groups + registry. + +6. References + +6.1. Normative References + + [FIPS203] "Module-lattice-based key-encapsulation mechanism + standard", National Institute of Standards and Technology + (U.S.), DOI 10.6028/nist.fips.203, August 2024, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [rfc7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves + for Security", RFC 7748, DOI 10.17487/RFC7748, January + 2016, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + [SP56A] 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, + DOI 10.6028/nist.sp.800-56ar3, April 2018, + . + + [SP56C] Barker, E., Chen, L., and R. Davis, "Recommendation for + Key-Derivation Methods in Key-Establishment Schemes", + National Institute of Standards and Technology, + DOI 10.6028/nist.sp.800-56cr2, August 2020, + . + +6.2. Informative References + + [DSS] Chen, L., Moody, D., Regenscheid, A., Robinson, A., and K. + Randall, "Recommendations for Discrete Logarithm-based + Cryptography:: Elliptic Curve Domain Parameters", National + Institute of Standards and Technology, + DOI 10.6028/nist.sp.800-186, February 2023, + . + + [ECDSA] American National Standards Institute, "Public Key + Cryptography for the Financial Services Industry: The + Elliptic Curve Digital Signature Algorithm (ECDSA)", + ANSI ANS X9.62-2005, November 2005. + + [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand + Key Derivation Function (HKDF)", RFC Editor, + DOI 10.17487/rfc5869, May 2010, + . + + [hybrid] Stebila, D., Fluhrer, S., and S. Gueron, "Hybrid key + exchange in TLS 1.3", Work in Progress, Internet-Draft, + draft-ietf-tls-hybrid-design-11, 7 October 2024, + . + + [tlsiana] Salowey, J. A. and S. Turner, "IANA Registry Updates for + TLS and DTLS", Work in Progress, Internet-Draft, draft- + ietf-tls-rfc8447bis-10, 3 November 2024, + . + + [xyber] Westerbaan, B. and D. Stebila, "X25519Kyber768Draft00 + hybrid post-quantum key agreement", Work in Progress, + Internet-Draft, draft-tls-westerbaan-xyber768d00-03, 24 + September 2023, . + +Appendix A. Change log + + * draft-kwiatkowski-tls-ecdhe-mlkem-03: + + - Adds P-384 combined with ML-KEM-1024 + + - Adds text that describes error-handling and outlines how the + client and server must ensure the integrity of the key exchange + process. + + - Adds note on the incompatibility of the codepoint name + X25519MLKEM768 with [hybrid]. + + - Various cosmetic changes. + + * draft-kwiatkowski-tls-ecdhe-mlkem-02: + + - Adds section that mentions supported groups that this document + obsoletes. + + - Fix a reference to encapsulation in the FIPS 203. + + * draft-kwiatkowski-tls-ecdhe-mlkem-01: + + - Add X25519MLKEM768 + + * draft-kwiatkowski-tls-ecdhe-mlkem-00: + + - Change Kyber name to ML-KEM + + - Swap reference to I-D.cfrg-schwabe-kyber with FIPS-203 + + - Change codepoint. New value is equal to old value + 1. + + * draft-kwiatkowski-tls-ecdhe-kyber-01: Fix size of key shares + generated by the client and the server + + * draft-kwiatkowski-tls-ecdhe-kyber-00: updates following IANA + review + +Authors' Addresses + + Kris 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@waterloo.ca diff --git a/draft-kwiatkowski-tls-ecdhe-mlkem-03/index.html b/draft-kwiatkowski-tls-ecdhe-mlkem-03/index.html new file mode 100644 index 0000000..c5ab3f0 --- /dev/null +++ b/draft-kwiatkowski-tls-ecdhe-mlkem-03/index.html @@ -0,0 +1,45 @@ + + + + post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem draft-kwiatkowski-tls-ecdhe-mlkem-03 preview + + + + +

Editor's drafts for draft-kwiatkowski-tls-ecdhe-mlkem-03 branch of post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem

+ + + + + + +
ECDHE-MLKEMplain textsame as main
+ + + diff --git a/index.html b/index.html index 673a392..ced676a 100644 --- a/index.html +++ b/index.html @@ -41,6 +41,14 @@

Preview for branch kris/exception

diff with main +

Preview for branch draft-kwiatkowski-tls-ecdhe-mlkem-03

+ + + + + + +
ECDHE-MLKEMplain textsame as main

Preview for branch gh-pages