LAKE Working Group G. Selander Internet-Draft J. Preuß Mattsson Intended status: Standards Track Ericsson Expires: 8 January 2026 7 July 2025 Quantum-Resistant Cipher Suites for EDHOC draft-spm-lake-pqsuites-00 Abstract The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC), achieves post-quantum security by adding new cipher suites with quantum-resistant algorithms, such as ML-KEM for key exchange and ML-DSA for digital signatures. This document specifies how EDHOC operates in a post-quantum setting using both signature-based and PSK-based authentication methods, and defines corresponding cipher suites. 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 8 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Selander & Preuß MattssonExpires 8 January 2026 [Page 1] Internet-Draft EDHOC PQC July 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. EDHOC with Quantum-Resistant Algorithms . . . . . . . . . . . 3 2.1. Using KEMs for EDHOC Key Exchange . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. EDHOC Method Type Registry . . . . . . . . . . . . . . . 5 5.2. EDHOC Cipher Suites Registry . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Lightweight Authenticated Key Exchange (LAKE) protocol, Ephemeral Diffie-Hellman over COSE (EDHOC) [RFC9528], supports the use of multiple authentication methods and the negotiation of cipher suites based on COSE algorithms. Currently, four asymmetric authentication methods (0, 1, 2, and 3) are defined. In addition, a symmetric key- based authentication method is being developed, see [I-D.ietf-lake-edhoc-psk]. The cipher suites defined in [RFC9528] rely on Elliptic Curve Cryptography (ECC) for key exchange and authentication, making them vulnerable in the event that a Cryptographically Relevant Quantum Computer (CRQC) is realized. This document specifies how EDHOC can operate in a post-quantum setting using both signature-based and PSK-based authentication, and defines corresponding cipher suites. Selander & Preuß MattssonExpires 8 January 2026 [Page 2] Internet-Draft EDHOC PQC July 2025 1.1. Terminology 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. Readers are expected to be familiar with EDHOC [RFC9528]. 2. EDHOC 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], is 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, a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM [I-D.ietf-jose-pqc-kem], can be applied directly to EDHOC, as is detailed in Section 2.1. To enable post-quantum security in EDHOC it suffices to register new cipher suites using COSE registered algorithms, see Section 5.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. An alternative path to post-quantum EDHOC, not pursued in this document, would be to define new authentication methods based on Key Encapsulation Mechanisms (KEMs). 2.1. Using KEMs for EDHOC Key Exchange Given a quantum-resistant KEM, such as ML-KEM-512, with encapsulation key ek, ciphertext c, and shared secret key K (using the notation of [FIPS203]). The Diffie-Hellman procedure in EDHOC 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. Selander & Preuß MattssonExpires 8 January 2026 [Page 3] Internet-Draft EDHOC PQC July 2025 * 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(c). * G_XY is the shared secret key K. The security requirements and security considerations of EDHOC and the KEM algorithm used apply. For example, the Initiator MUST generate a new encapsulation / decapsulation key pair for each EDHOC session. Note that G_Y does not contain a public key when a KEM is used in this way. Note also that this use of KEM applies both to standalone KEM and hybrid KEMs such as, e.g., X-wing [I-D.connolly-cfrg-xwing-kem]. 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. Compared to elliptic curve algorithms such as ECDHE, ECDSA, and EdDSA, ML-KEM-512 and ML-DSA-44 introduce significantly higher overhead [FIPS203][FIPS204]. In the future, more efficient post- quantum signature schemes such as FN-DSA and MAYO may be considered, but these are not standardized at the time of this document’s publication. Cipher suites using ML-KEM-512 [I-D.ietf-jose-pqc-kem] for key exchange and ML-DSA-44 [I-D.ietf-cose-dilithium] for digital signatures are specified in Section 5.2. As both ML-KEM [FIPS203] and ML-DSA [FIPS204] internally use SHAKE256, it is natural to also use SHAKE256 for EDHOC's key derivation. 3. 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 contrast, the cipher suites specified in this document use the quantum-resistant algorithms ML-KEM for key exchange and ML-DSA for authentication. When used with Method 0 from [RFC9528], where both the Initiator and Responder authenticate using digital signatures, or with the PSK method defined in [I-D.ietf-lake-edhoc-psk], these cipher suites preserve the same security properties even in the presence of a quantum-capable adversary. Selander & Preuß MattssonExpires 8 January 2026 [Page 4] Internet-Draft EDHOC PQC July 2025 Security considerations of ML-KEM are discussed in [I-D.sfluhrer-cfrg-ml-kem-security-considerations]. 4. Privacy Considerations TBD 5. IANA Considerations 5.1. EDHOC Method Type Registry IANA is requested to update the EDHOC Method Type registry with a column with heading "Requires DH/NIKE" indicating that the method requires Diffie-Hellman or Non-Interactive Key Exchange. Valid table entries in this column are "Yes" and "No". For the existing Method Types, the following entries are inserted in the new "Requires DH/NIKE" column: Value: 0, Requires DH/NIKE: No Value: 1, Requires DH/NIKE: Yes Value: 2, Requires DH/NIKE: Yes Value: 3, Requires DH/NIKE: Yes 5.2. EDHOC Cipher Suites Registry IANA is requested to update the EDHOC Cipher Suites registry with a column with heading "Supports DH/NIKE" indicating that the cipher suite supports Diffie-Hellman or Non-Interactive Key Exchange. Valid table entries in this column are "Yes" and "No". For the existing EDHOC Cipher Suites, 0-6, 24, 25, the entry "Yes" is inserted in the new "Supports DH/NIKE" column. Furthermore, IANA is requested to register the following entries in the EDHOC Cipher Suites Registry: Value: TBD1 Array: 30, -45, 16, TBD3, -48, 10, -16 Description: AES-CCM-16-128-128, SHAKE256, 16, MLKEM512, ML-DSA-44, AES-CCM-16-64-128, SHA-256 Supports DH/NIKE: No Reference: [[This document]] Selander & Preuß MattssonExpires 8 January 2026 [Page 5] Internet-Draft EDHOC PQC July 2025 Value: TBD2 Array: 3, -45, 16, TBD3, -48, 30, -16 Description: A256GCM, SHAKE256, 16, MLKEM512, ML-DSA-44, A256GCM, SHA-256 Supports DH/NIKE: No Reference: [[This document]] 6. References 6.1. Normative References [I-D.ietf-cose-dilithium] Prorock, M., Steele, O., Misoczki, R., Osborne, M., and C. Cloostermans, "ML-DSA for JOSE and COSE", Work in Progress, Internet-Draft, draft-ietf-cose-dilithium-07, 12 June 2025, . [I-D.ietf-jose-pqc-kem] Reddy.K, T., Banerjee, A., and H. Tschofenig, "Post- Quantum Key Encapsulation Mechanisms (PQ KEMs) for JOSE and COSE", Work in Progress, Internet-Draft, draft-ietf- jose-pqc-kem-01, 6 May 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, . 6.2. Informative References [FIPS203] "Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, August 2024, . Selander & Preuß MattssonExpires 8 January 2026 [Page 6] Internet-Draft EDHOC PQC July 2025 [FIPS204] "Module-Lattice-Based Digital Signature Standard", NIST FIPS 204, August 2024, . [I-D.connolly-cfrg-xwing-kem] Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing: general-purpose hybrid post-quantum KEM", Work in Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem- 07, 3 May 2025, . [I-D.ietf-lake-edhoc-psk] Lopez-Perez, Selander, G., Mattsson, J. P., and R. Marin- Lopez, "EDHOC Authenticated with Pre-Shred Keys (PSK)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc- psk-03, 1 March 2025, . [I-D.sfluhrer-cfrg-ml-kem-security-considerations] Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D. Shiu, "ML-KEM Security Considerations", Work in Progress, Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security- considerations-03, 15 May 2025, . Acknowledgments This work was supported partially by Vinnova - the Swedish Agency for Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS. Authors' Addresses Göran Selander Ericsson Email: goran.selander@ericsson.com John Preuß Mattsson Ericsson Email: john.mattsson@ericsson.com Selander & Preuß MattssonExpires 8 January 2026 [Page 7]