Strengthening COSE ECDH-ES Against Downgrading Attacks

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 April 2026.¶

Copyright Notice

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

[RFC9052] and [RFC9053] define COSE and the use of ECDH‑ES with HKDF and AES Key Wrap. The key material for content encryption (CEK) or key‑encryption keys (KEK) is derived via a KDF context that does not cover all recipient metadata. As discussed on the COSE mailing list and in work on CMS [RFC9709], unauthenticated recipient metadata can enable algorithm‑substitution and downgrade attacks.¶

COSE‑HPKE [I-D.ietf-cose-hpke] introduced a Recipient_structure that is deterministically encoded and used as the HPKE info parameter to bind the next‑layer algorithm identifier and recipient‑protected headers into the key derivation. This document specifies an analogous change for COSE ECDH‑ES: when an ECDH‑ES algorithm is used in a COSE_recipient, the COSE_KDF_Context is replaced with a Recipient_structure and the derived key is computed accordingly.¶

This specification is intended for use cases including firmware encryption, see [I-D.ietf-suit-firmware-encryption], where ECDH‑ES is used.¶

2. 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.¶

CBOR and COSE terminology are as in [RFC9052] and [RFC9053].¶

3. Overview

This document defines the ECDH‑ES Recipient_structure, a deterministic CBOR structure modeled after the HPKE Recipient_structure. Implementations use it in place of COSE_KDF_Context for ECDH‑ES recipients. The construction provides integrity for recipient‑protected headers and cryptographically binds the next‑layer algorithm to the derived key. It is applicable both when ECDH‑ES derives a CEK directly (ECDH‑ES+HKDF-) and when ECDH‑ES derives a KEK for AES‑KW (ECDH‑ES+AKW).¶

To avoid interoperability failures with existing deployments, this document registers new COSE algorithm identifiers that signal use of this construction.¶

4. ECDH‑ES Recipient_structure

The structure is identical to the one in COSE‑HPKE except for the context string. The deterministic CBOR encoding defined in [RFC8949] Section 4.2.1 MUST be used.¶

ECDH-ES-Recipient-structure = [
  context: "ECDH-ES Recipient",
  next_layer_alg: int / tstr,
  recipient_protected_header: empty_or_serialize_map,
  recipient_extra_info: bstr
]

• context contains the fixed text string "ECDH-ES Recipient" to distinguish this structure from the COSE-HPKE-defined recipient_structure¶

• next_layer_alg is the algorithm identifier for the next lower COSE layer (the content‑encryption algorithm used with the CEK or the key‑wrap algorithm). This value MUST equal the alg parameter in that lower layer.¶

• recipient_protected_header is the deterministic CBOR encoding of the protected header parameters of the COSE_recipient.¶

• recipient_extra_info allows applications to include additional context into key derivation (e.g., identifiers). If unused, set to the zero‑length byte string.¶

5. Processing Rules

When an ECDH‑ES algorithm defined in this document is used in a COSE_recipient, the following rules apply.¶

6. New COSE Algorithm Identifiers

This document registers new COSE algorithms that mirror the existing ECDH‑ES algorithms but signal the use of the Recipient_structure in key derivation. The semantics and key types are otherwise unchanged from [RFC9053].¶

Rationale:* Aligns with existing COSE registrations and keeps HKDF hash choices consistent with [RFC9053]. If a future need arises, variants using HKDF‑SHA‑512 for AES‑KW MAY be registered.¶

7. CDDL

The following CDDL augments [RFC9052] and [RFC9053].¶

empty_or_serialize_map = bstr .cbor map / bstr .size 0

ECDH-ES-Recipient-structure = [
  context: "ECDH-ES Recipient",
  next_layer_alg: int / tstr,
  recipient_protected_header: empty_or_serialize_map,
  recipient_extra_info: bstr
]

8. Backward Compatibility

The construction in this document intentionally changes the KDF info input compared to [RFC9053], and therefore produces different keys. Messages created using the algorithms in Section 6 are not interoperable with messages produced using the legacy ECDH‑ES algorithms. This is by design and prevents silent downgrade.¶

Implementations that need to accept legacy messages MAY support both sets of algorithms. Senders SHOULD prefer the new -RS algorithms when a recipient advertises support.¶

9. Security Considerations

This specification provides two main security benefits:¶

• Header Binding: By incorporating the deterministically encoded recipient_protected_header into the HKDF info, protected header parameters (including kid and any algorithm signals) are cryptographically bound to the derived key. An attacker cannot flip recipient‑protected parameters without causing decryption failure.¶

• Algorithm Binding: Binding next_layer_alg prevents algorithm‑substitution and downgrade of the content‑encryption or key‑wrap algorithm. This addresses attack classes discussed in [RFC9709] and analogous to LAMPS findings applied to other formats.¶

Applications SHOULD continue to place all security‑critical recipient parameters into the protected header. Applications SHOULD NOT place large or bulk external data into recipient_extra_info; use external_aad at layer 0 if such data needs integrity protection.¶

10. IANA Considerations

IANA is requested to register the algorithms in Section 6 in the "COSE Algorithms" registry under the following template:¶

• Name: as in Section 6¶

• Value: TBD (to be assigned by IANA)¶

• Description: as in Section 6¶

• Change Controller: IESG¶

• Reference: This document¶

• Recommended: as in Section 6¶

• Capabilities: [derive]¶

• Key Type: EC2, OKP¶

No new header parameters are defined by this document.¶

11. Example

This section provides an abbreviated example for ECDH-ES-RS+HKDF-256 protecting a single recipient. Hex strings are illustrative.¶

RS := [
  "ECDH-ES Recipient",
  1,                                     ; A128GCM at layer 0
  << {1: -100, 4: h'11aa22bb'} >>,        ; { alg: ECDH-ES-RS+HKDF-256, kid: ... }
  h''
]

IKM = Z
salt = (absent)
info = encode_deterministic(RS)
CEK  = HKDF-Expand(HKDF-Extract(salt, IKM), info, 16)

12. References

Acknowledgments

Thanks to Ilari Liusvaara and the COSE working group for discussions and to the SUIT and TEEP working group participants for motivating use cases.¶

Authors' Addresses