Quantum-Resistant Cipher Suites for LAKE

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 23 March 2027.¶

Copyright Notice

Copyright (c) 2026 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

The Lightweight Authenticated Key Exchange (LAKE) protocol defined in [RFC9528], previously known as Ephemeral Diffie-Hellman over COSE (EDHOC), supports multiple authentication methods and negotiation of cipher suites based on COSE algorithms. Four asymmetric authentication methods (0–3) are defined in [RFC9528]. A symmetric key-based authentication method and a Key Encapsulation Mechanism (KEM)-based authentication method are being developed; see [I-D.ietf-lake-edhoc-psk] and [I-D.ietf-lake-authkem-edhoc], respectively.¶

The cipher suites defined in [RFC9528] rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication. While ECC is well suited to constrained environments, it is vulnerable to attacks by a Cryptographically Relevant Quantum Computer (CRQC).¶

This document specifies how the LAKE protocol operates in a post-quantum setting by defining new cipher suites using ML-KEM [I-D.ietf-jose-pqc-kem] for key exchange and ML-DSA [I-D.ietf-cose-dilithium] for digital signatures. ML-KEM provides a post-quantum replacement for the ephemeral Diffie-Hellman key exchange. The new cipher suites can be used with signature-based authentication, as well as with the PSK-based and KEM-based authentication methods being developed; see Section 3.6 of [RFC9528] on algorithms not used in certain methods.¶

KEM algorithms such as ML-KEM are not Diffie-Hellman or Non-Interactive Key Exchange (DH/NIKE) primitives. Consequently, the new ML-KEM cipher suites cannot be used with methods 0–3, which require DH/NIKE. This document therefore updates the EDHOC Method Types and Cipher Suites registries to add columns indicating, respectively, whether a method requires and whether a cipher suite supports DH/NIKE-based key exchange; see Section 6.1 and Section 6.2. The new cipher suites combining ML-KEM and ML-DSA are registered accordingly.¶

With the addition of KEM-based key exchange, the protocol is no longer dependent on Diffie-Hellman, and the name Ephemeral Diffie-Hellman over COSE (EDHOC) no longer accurately describes the protocol. Accordingly, this document updates [RFC9528] by changing the name of the protocol from EDHOC to Lightweight Authenticated Key Exchange (LAKE). The EDHOC prefix is retained where needed to avoid ambiguity with terminology and registry entries defined in [RFC9528], for example in the IANA registries.¶

2. LAKE with Quantum-Resistant Algorithms

Method 0 in [RFC9528], which uses digital signatures for authentication by both the Initiator and Responder, and also the PSK method in [I-D.ietf-lake-edhoc-psk], are straightforward to use with standardized post-quantum algorithms.¶

A quantum-resistant signature algorithm, such as ML-DSA [I-D.ietf-cose-dilithium], is a drop-in replacement for classical signature algorithms such as ECDSA. For post-quantum secure key exchange, in order to replace the Ephemeral Diffie-Hellman key exchange, a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM [I-D.ietf-jose-pqc-kem], can be applied directly to the LAKE protocol, as is detailed in Section 3.¶

To enable post-quantum security support for LAKE it suffices to register new cipher suites using COSE registered algorithms. Cipher suites using ML-KEM-512 and ML-KEM-1024 [I-D.ietf-jose-pqc-kem] for key exchange, and ML-DSA-44 and ML-DSA-87 [I-D.ietf-cose-dilithium] for digital signatures are specified in Section 6.2. As both ML-KEM [FIPS203] and ML-DSA [FIPS204] internally use SHAKE256 [FIPS202], it was natural to have SHAKE256 as EDHOC hash algorithm in the cipher suite, and thus used also in the key derivation, see Section 4 of [RFC9528]. Note that as application hash function in these cipher suites, the legacy algorithms SHA-256 or SHA-384 are still used, see Section 6.2. Additional post-quantum cipher suites may be specified.¶

Methods 1–3 in [RFC9528] use a Diffie-Hellman/Non-Interactive Key Exchange (NIKE) based API for authentication. As of this writing, no standardized post-quantum algorithms for these methods exist. To highlight which methods require DH/NIKE, a column is added to the EDHOC Method Type registry, see Section 6.1. To highlight matching cipher suites, a corresponding column indicating support for DH/NIKE is added, see Section 6.2.¶

An alternative path to post-quantum support for the LAKE protocol, pursued in [I-D.ietf-lake-authkem-edhoc], is to define new authentication methods based on Key Encapsulation Mechanisms (KEMs). The cipher suites defined in this document can also be used with these authentication methods.¶

Compared to elliptic curve algorithms such as ECDHE, ECDSA, and EdDSA, ML-KEM and ML-DSA introduce significantly higher overhead (see [FIPS203] and [FIPS204] respectively), but currently are the most lightweight standardized post-quantum algorithms to use with LAKE. More efficient post-quantum signature schemes are being standardized, such as FN-DSA, which could offer smaller signatures. This remains a possible direction for future research, analysis and standardization, after which they may be included in new cipher suites.¶

However, it is important to note that these cipher suites may not be usable for certain classes of constrained devices (see [I-D.ietf-iotops-7228bis]) due to, e.g., increased size of signatures or of KEM keys in quantum-resistant algorithms.¶

3. Using KEMs in the Key Exchange

Given a quantum-resistant KEM, such as ML-KEM-512, with encapsulation key ek, decapsulation key dk, ciphertext c, and shared secret key K (using the notation of [FIPS203]), the Diffie-Hellman procedure in the key exchange is replaced by a KEM procedure as follows:¶

• The Initiator generates a new encapsulation / decapsulation key pair matching the selected cipher suite.¶

• The encapsulation key ek is transported in the G_X field in message_1.¶

• The Responder calculates (K,c) = Encaps(ek).¶

• The ciphertext c is transported in the G_Y field in message_2.¶

• The Initiator calculates the shared secret K = Decaps(dk, c).¶

• G_XY is the shared secret key K.¶

The security requirements and security considerations of [RFC9528] and of the KEM algorithm used apply. For example, the Initiator MUST generate a new encapsulation / decapsulation key pair for each LAKE session.¶

Note that G_Y does not contain a public key when a KEM is used in this way. The definition of LAKE message_2 in Section 5.3.1 of [RFC9528] remains the same:¶

message_2 = (
  G_Y_CIPHERTEXT_2 : bstr,
)

and G_Y_CIPHERTEXT_2 remains the concatenation of G_Y and CIPHERTEXT_2, the latter is defined in Section 5.3.2 of [RFC9528]. But now G_Y is a KEM ciphertext.¶

Just as with the ephemeral key G_Y, the length of KEM ciphertext c is known from the corresponding algorithm in the selected cipher suite, see Table 1. Hence the Initiator can separate out the concatenated ciphertexts, decapsulate and decrypt, respectively.¶

Note also that this use of KEM applies both to standalone KEM and composite hybrid KEMs such as, e.g., [I-D.irtf-cfrg-concrete-hybrid-kems].¶

Conventions for using post-quantum KEMs within COSE are described in [I-D.ietf-jose-pqc-kem]. The shared secret key K corresponds to the initial shared secret SS' in that document.¶

4. Security Considerations

The cipher suites defined in [RFC9528] rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication, which would be broken by a Cryptographically Relevant Quantum Computer (CRQC). In this section we discuss the security considerations brought by the new cipher suites.¶

5. Privacy Considerations

This document does not add any new privacy considerations to those discussed in [RFC9528].¶

6. IANA Considerations

This section specifies updates to the EDHOC Method Types and Cipher Suites registries.¶

7. References

Acknowledgments

This work was supported partially by Vinnova - the Swedish Agency for Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS.¶

Authors' Addresses