Quantum-Resistant Cipher Suites for EDHOC
draft-spm-lake-pqsuites-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Göran Selander , John Preuß Mattsson | ||
| Last updated | 2025-07-06 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-spm-lake-pqsuites-00
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, <https://datatracker.ietf.org/doc/html/draft-
ietf-cose-dilithium-07>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-jose-
pqc-kem-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528,
DOI 10.17487/RFC9528, March 2024,
<https://www.rfc-editor.org/rfc/rfc9528>.
6.2. Informative References
[FIPS203] "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", NIST FIPS 203, August 2024,
<https://doi.org/10.6028/NIST.FIPS.203>.
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,
<https://doi.org/10.6028/NIST.FIPS.204>.
[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, <https://datatracker.ietf.org/doc/html/
draft-connolly-cfrg-xwing-kem-07>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-lake-
edhoc-psk-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-sfluhrer-
cfrg-ml-kem-security-considerations-03>.
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]