Ratcheted CoAP: A Forward-Secure Delta over OSCORE for Highly Constrained Wake-Send-Sleep Devices

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

OSCORE [RFC8613] provides end-to-end confidentiality, integrity, and replay protection for CoAP [RFC7252] with no handshake and minimal per-message overhead, by deriving a Sender Key once from a shared Common Context and reusing it for the lifetime of the security context (up to 2^40 messages). This is an excellent fit for constrained devices that wake, send, and sleep.¶

It has one gap by design: the Sender Key is static. If a device is physically captured and its key material is extracted, every message that device ever sent becomes retroactively decryptable. For unattended field devices -- soil sensors, wildlife trackers, disaster-response beacons, agricultural nodes -- physical capture is a realistic threat, not a theoretical one.¶

EDHOC [RFC9528] was standardized by the LAKE working group specifically to close this gap: a compact authenticated Diffie-Hellman handshake that establishes an OSCORE security context with genuine, DH-strength forward secrecy. For the large majority of constrained deployments, EDHOC followed by OSCORE is the correct, already-standardized answer, and this document does not attempt to replace it.¶

EDHOC's handshake, however, is not free: published measurements show on the order of 130 bytes and 1.5 round trips across its three messages, and hundreds of milliseconds to several seconds of compute on typical constrained microcontrollers (see Section 2). For devices that wake extremely rarely relative to their operational lifetime, or that sit on links where every round trip is expensive or unreliable (deep LoRa, satellite backhaul), that one-time cost can dominate the device's entire energy or airtime budget. RCOAP is offered as a narrower, explicitly weaker-guarantee alternative for that specific residual niche.¶

RCOAP replaces OSCORE's static Sender Key with a one-way hash ratchet: each transmission derives a new key from the previous one via HKDF, and the old key is never needed again. Capturing a device's current ratchet state exposes only messages sent after capture, never messages sent before it. This is a strictly weaker property than EDHOC's DH-based forward secrecy -- it rests on the one-wayness of a hash function against an adversary who has not yet captured the device, not on the hardness of a Diffie-Hellman problem -- but it requires no interactivity at all, matching OSCORE's zero-round-trip behavior exactly.¶

This document is an individual submission at an early stage. It has not received IETF review. Section 10 and Section 13 describe validation performed to date and open problems. The author is specifically seeking feedback on whether the niche described in Section 2 is real and narrow enough to matter, or whether EDHOC's cost, in practice, is already acceptable for essentially all real deployments -- in which case this document should not proceed.¶

2. Motivation and Applicability

RCOAP is applicable only to a narrow class of deployments where all of the following hold:¶

• The device wakes and transmits rarely relative to its operational lifetime (e.g., hourly or less), such that a one-time handshake's amortized cost is not negligible.¶
• The device's compute budget makes even EDHOC's Diffie-Hellman operations (hundreds of milliseconds to seconds on typical constrained MCUs) a significant fraction of its energy budget per wake cycle.¶
• The link is expensive or unreliable per round trip (e.g., deep LoRa, satellite), such that avoiding any handshake -- even a 1.5-round-trip one -- has outsized value.¶
• A weaker, symmetric-key-based forward-secrecy guarantee is an acceptable trade-off against EDHOC's stronger Diffie-Hellman-based guarantee for the application's risk model.¶

Outside this intersection, EDHOC plus OSCORE is almost certainly the better-engineered, better-reviewed, and already-standardized choice, and implementers should use it instead. This document does not claim RCOAP is a general improvement over EDHOC; it claims a specific, bounded residual gap and asks the working groups closest to this space to judge whether that gap is worth filling.¶

3. Non-Goals

• RCOAP is not a general-purpose transport-security replacement for TCP/TLS, UDP/DTLS, or QUIC.¶
• RCOAP does not address multi-path delivery, congestion control, or large payload transfer.¶
• RCOAP does not provide future secrecy. Compromise of the current ratchet state permits computation of, and forgery under, all subsequent keys until the receiver detects an anomaly and the device is re-provisioned. This is an explicit, documented trade-off of the non-interactive design, not an oversight.¶

4. Root Provisioning

At provisioning time, out of band (e.g. USB, NFC, or factory flashing), the device and the receiver are configured with a shared 32-byte root secret K0, generated by a cryptographically secure random number generator. The device additionally stores a 4-byte DeviceID and a message counter n, initialized to zero. The receiver stores the same values plus a lookahead cache described in Section 7.¶

5. Key Ratchet

Each key in the chain is derived from its predecessor by:¶

K_n = HKDF-Expand-SHA256(K_{n-1}, info="ratchet-wake", L=32)

This derivation is one-way: possession of K_n does not permit recomputation of any K_0 through K_(n-1). It requires a single HMAC-SHA256 invocation, well within budget on Cortex-M0+, ESP32, and nRF52-class hardware.¶

The device MUST advance the ratchet and increment n before attempting transmission, and MUST persist the updated (K_current, n) pair to non-volatile storage before radio activity begins, so that a power loss during transmission cannot cause key reuse across two messages.¶

6. Wire Format

The wire format deliberately mirrors OSCORE's compact flag-byte- plus-variable-fields philosophy so the delta against [RFC8613] Section 6 is easy to audit.¶

Byte 0:       Flag byte
                bits 0-2: counter length (n bytes, 1-4)
                bit 3:    ack-requested flag
                bits 4-7: reserved, MUST be 0
Byte 1-4:     DeviceID (4 bytes, fixed-width; not compressed like
              OSCORE's variable-length kid, on the assumption that
              deployments in this niche are small enough that a fixed-
              width lookup outweighs variable-length savings)
Byte 5..5+n:  Counter (n bytes, big-endian; matches OSCORE's Partial IV
              encoding convention)
(12 bytes,
 not on wire): Nonce = SHA-256(DeviceID || Counter)[0:12], computed
              independently by both sides, never transmitted
Payload:      ChaCha20-Poly1305 ciphertext under key K_n
Trailer:      16-byte Poly1305 authentication tag

Minimum overhead in this configuration is 22 bytes (5-byte flag+DeviceID, 1-byte counter, 16-byte tag), larger than OSCORE's best case of roughly 4 bytes, because RCOAP is link-layer agnostic and cannot rely on an underlying CoAP header to already carry part of this framing. An optional compact mode, using a shorter authentication tag and an implicit, pre-shared DeviceID mapping, can match OSCORE's own per-payload-size overhead exactly at the cost of reduced forgery resistance (2^-64) and a bound on the number of devices sharing a gateway (256); see the accompanying implementation report for measurements.¶

7. Replay Protection and Resynchronization

The receiver precomputes and caches the next W ratchet-derived keys ahead of the last-accepted counter n_last, where W defaults to 32, matching the default replay window size in [RFC8613] Section 3.2.2. An incoming message is accepted if its counter falls within [n_last+1, n_last+W] and its Poly1305 tag verifies under the corresponding derived key. On acceptance, the receiver advances its own ratchet state to that point and discards all older cached keys, which is what makes forward secrecy hold on the receiver side as well as the device side.¶

If a device's counter has drifted beyond the window (for example, after W or more consecutive lost transmissions), an explicit resynchronization exchange is required. This is intentionally the rare, interactive path; RCOAP's zero-round-trip property applies to the common case, not to recovery from extended message loss. A full resync protocol is described in a companion document rather than this specification, to keep the base wire format's review scope narrow; see the implementation report referenced in Section 10.¶

8. Optional Acknowledgement

An acknowledgement is sent only if bit 3 of the flag byte was set on the corresponding request. Its format is the echoed counter, at the same width as the request, followed by a Poly1305 tag over that counter, keyed with K_n. A device that did not set the ack-requested bit MUST NOT open a receive window, to minimize radio-on time in the default, non-acknowledged path.¶

9. Comparison to OSCORE and EDHOC+OSCORE

10. Implementation Status

This section records the status of a reference implementation at the time of this submission, per the guidance of [RFC7942]. It is expected to be removed before publication as an RFC, should this document proceed that far.¶

A Rust reference implementation exists and has been exercised as follows: 35 unit tests covering core logic; 13 hand-written adversarial tests (replay, forgery, tampering, boundary conditions, cross-device confusion), all blocked; 600,000 fuzz inputs against the decoder and receiver with zero panics; 40 simulated abrupt process kills across 500-plus messages with zero observed key or counter reuse; an independent Python implementation built from the specification text alone, demonstrating full bidirectional interoperability; and execution of the on-chip logic, unmodified, under three independent emulators (QEMU ARM Cortex-M3, Renode nRF52840-DK, and QEMU RISC-V).¶

The implementation has never been run on physical hardware, and this specification and its implementation have not received independent human security review. Both are necessary before any production use; see Section 13.¶

11. Security Considerations

RCOAP provides forward secrecy against physical device capture: an adversary who extracts a device's current ratchet key and counter cannot recover keys used for prior messages, because the ratchet derivation is one-way. This guarantee rests on the pseudorandomness of HKDF-SHA256 and does not rely on any computational hardness assumption analogous to Diffie-Hellman; implementers requiring the stronger, better-studied guarantee should use EDHOC [RFC9528] with OSCORE instead.¶

RCOAP provides no future secrecy. An adversary who extracts the current key and counter can compute and forge all subsequent messages until the compromise is detected and the device is re-provisioned with a fresh root secret out of band. Applications with a risk model that requires bounding the impact of an undetected, ongoing compromise, rather than only a discrete capture-and-inspect event, are not well served by RCOAP.¶

The nonce derivation, SHA-256(DeviceID || Counter), is deterministic and depends on the counter never repeating under a given key, which the ratchet-plus-persist-before-transmit design in Section 5 is intended to guarantee; an implementation that fails to persist (K_current, n) before radio activity risks nonce reuse under key reuse following a crash or power loss, which would be catastrophic for the AEAD's confidentiality guarantee.¶

The optional compact mode traffic-offs a shorter authentication tag for reduced per-message size; implementers MUST evaluate whether the resulting forgery resistance is acceptable for their threat model before enabling it, and MUST NOT exceed the device count bound associated with that tag length.¶

This specification and its reference implementation have not undergone independent cryptographic review. No claims in this document should be treated as validated for production use ahead of such review; see Section 13.¶

12. IANA Considerations

This document has no IANA actions at this time. Should this work proceed, allocation of a flag-byte reserved-bit registry, or reuse of an existing COSE/CoAP registry, may be proposed in a future revision.¶

13. Open Issues and Limitations

• No formal or symbolic security analysis (e.g. Tamarin or ProVerif model) exists yet; only informal, self-conducted adversarial analysis.¶
• The resynchronization exchange after large counter drift is not fully specified in this document.¶
• Multi-replica receiver coordination (a load-balanced fleet of receivers sharing ratchet state) is undesigned.¶
• CoAP extensions Block-wise Transfer and Observe are not yet addressed.¶
• Distributed, many-source denial-of-service is only partially mitigated; single-source flooding is bounded, many-source flooding is not.¶
• The applicability niche described in Section 2 has not been validated against real deployment data; feedback from LAKE and CoRE participants on whether it is real and significant is explicitly requested.¶

14. Acknowledgements

This document builds directly on the design of OSCORE [RFC8613] and takes its comparison baseline from EDHOC [RFC9528], developed by the IETF LAKE working group. Any errors in characterizing either are the author's own.¶

Appendix A. Per-Payload-Size Overhead (Informative)

Measured against the reference implementation described in Section 10, comparing OSCORE's typical overhead to RCOAP in both its full and compact modes:¶

Compact mode's byte parity with OSCORE is achieved by shortening the authentication tag; see Section 11 for the associated trade-off before using compact mode.¶

Author's Address