]> Update to Post-quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 TU Dresden
Dresden Germany muhammad_usama.sardar@tu-dresden.de
Security Transport Layer Security hybrid post-quantum This is a quick update of to-be RFC for recommending the three hybrid key agreement mechanisms in TLS 1.3. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction The readers are assumed to be familiar with and .
Motivation Given the risk of "hardvest-now, decrypt-later" attacks , we believe that the hybrid key agreement mechanisms need to be recommended. defines the meaning of "Y" in "Recommended" column as follows:
Y: Indicates that the IETF has consensus that the item is RECOMMENDED. This only means that the associated mechanism is fit for the purpose for which it was defined. Careful reading of the documentation for the mechanism is necessary to understand the applicability of that mechanism. The IETF could recommend mechanisms that have limited applicability but will provide applicability statements that describe any limitations of the mechanism or necessary constraints on its use.
This draft aims to build the mentioned consensus.
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 when, and only when, they appear in all capitals, as shown here.
Security Considerations The security considerations of apply.
IANA Considerations This document requests the following updates to three entries in the TLS Supported Groups registry, according to the procedures in .
SecP256r1MLKEM768
Recommended:
Y
X25519MLKEM768
Recommended:
Y
SecP384r1MLKEM1024
Recommended:
Y
Value Description Recommended
4587 SecP256r1MLKEM768 Y
4588 X25519MLKEM768 Y
4589 SecP384r1MLKEM1024 Y
References Normative References Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 PQShield AWS Cloudflare University of Waterloo This draft defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 - that combine the post-quantum ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) with an ECDHE (Elliptic Curve Diffie- Hellman) exchange. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IANA Registry Updates for TLS and DTLS This document updates the changes to the TLS and DTLS IANA registries made in RFC 8447. It adds a new value, "D" for discouraged, to the "Recommended" column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447. Post-Quantum Cryptography for Engineers Nokia Nokia Nokia DigiCert Entrust Limited The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), detailing the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms.
Acknowledgments We thank the authors and contributors of for their work. We thank Eric Rescorla for this proposal. We also thank Bas Westerbaan for the initial idea.