]> SandboxAQ

durumcrustulum@gmail.com

Security Transport Layer Security mlkem tls post-quantum This memo defines ML-KEM as a standalone NamedGroup for use in TLS 1.3 to achieve post-quantum key agreement. About This Document 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

Motivation FIPS 203 standard (ML-KEM) is a new FIPS / CNSA 2.0 standard for post-quantum key agreement via lattice-based key establishment mechanism (KEM). Having a fully post-quantum (not hybrid) FIPS-compliant key agreement option for TLS 1.3 is necessary for eventual movement beyond hybrids and for users that need to be fully post-quantum sooner than later.

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.

Construction We align with except that instead of joining ECDH options with a KEM, we just have the KEM as a NamedGroup.

Security Considerations TLS 1.3's key schedule commits to the the ML-KEM encapsulation key and the encapsulated shared secret ciphertext, providing resilience against re-encapsulation attacks against KEMs used for key agreement. ML-KEM is MAL-BIND-K-PK-secure but only LEAK-BIND-K-CT and LEAK-BIND-K,PK-CT-secure, but because of the inclusion of the ML-KEM ciphertext in the TLS 1.3 key schedule there is no concern of malicious tampering (MAL) adversaries, not just honestly-generated but leaked key pairs (LEAK adversaries). The same is true of other KEMs with weaker binding properties, even if they were to have more constraints for secure use in contexts outside of TLS 1.3 handshake key agreement.These computational binding properties for KEMs were formalized in .

IANA Considerations This document requests/registers two new entries to the TLS Named Group (or Supported Group) registry, according to the procedures in .

Value:

0x0768 (please)

Description:

MLKEM768

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

FIPS 203 version of ML-KEM-768

Value:

0x1024 (please)

Description:

MLKEM1024

DTLS-OK:

Y

Recommended:

N

Reference:

This document

Comment:

FIPS 203 version of ML-KEM-1024

References Normative References This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. 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. 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 CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security CISPA Helmholtz Center for Information Security University of Waterloo Cisco Systems University of Haifa Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. Venafi sn3rd This document updates the changes to 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. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447.

Acknowledgments TODO acknowledge.