]>

divyanshuchoudhary2508@gmail.com

Security Individual Submission OSCORE CoAP forward secrecy key ratchet constrained devices This document specifies RCOAP, a compact, zero-round-trip, link-layer agnostic object-security mechanism for highly constrained devices that transmit infrequently. RCOAP is a targeted delta over OSCORE (): instead of a single long-lived Sender Key, RCOAP derives a fresh symmetric key for every message via a one-way hash ratchet. This bounds the impact of physical device capture to future messages only, at the cost of a modest per-message size increase and the loss of future secrecy. RCOAP is explicitly scoped to a narrow niche left open between OSCORE and EDHOC (): devices for which even EDHOC's one-time handshake cost is disproportionate to their message rate or compute budget. This document is a first individual submission, has not been reviewed by the IETF, and requests feedback in particular from the LAKE and CoRE working groups on whether this gap is real and worth standardizing, or already adequately covered.

Introduction OSCORE provides end-to-end confidentiality, integrity, and replay protection for CoAP 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 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 ). 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. and describe validation performed to date and open problems. The author is specifically seeking feedback on whether the niche described in 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.

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.

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.

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 .

Key Ratchet Each key in the chain is derived from its predecessor by: 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.

Wire Format The wire format deliberately mirrors OSCORE's compact flag-byte- plus-variable-fields philosophy so the delta against Section 6 is easy to audit. 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.

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

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.

Comparison to OSCORE and EDHOC+OSCORE Property comparison

Property	OSCORE alone	EDHOC + OSCORE	RCOAP
Forward secrecy	No	Yes (DH-based)	Yes (hash-ratchet-based, weaker guarantee)
Handshake	None	One-time, ~130 bytes, 1.5 RTT	None (every message zero-RTT)
Steady-state per-message overhead	Lowest	Same as OSCORE after setup	Slightly higher than OSCORE, even in compact mode
Re-keying cost	N/A	Requires a fresh handshake	Free; every wake is a new key
Device capture exposes	All historical messages	Messages until next handshake	Only future messages
Maturity	RFC since 2019, deployed	RFC since 2024, active deployment interest	Individual draft, self-reviewed only

Implementation Status This section records the status of a reference implementation at the time of this submission, per the guidance of . 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 .

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

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.

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 has not been validated against real deployment data; feedback from LAKE and CoRE participants on whether it is real and significant is explicitly requested.

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

Normative References Informative References

Per-Payload-Size Overhead (Informative) Measured against the reference implementation described in , comparing OSCORE's typical overhead to RCOAP in both its full and compact modes: Overhead by payload size

Payload	OSCORE	RCOAP (full)	RCOAP (compact)
4 bytes	15 B	26 B (+73%)	15 B (+0%)
16 bytes	27 B	38 B (+41%)	27 B (+0%)
256 bytes	267 B	278 B (+4%)	267 B (+0%)

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