notes: events/talks/kericonf26-02-argoud-kram

This data as json

path title type status classification words body
events/talks/kericonf26-02-argoud-kram Ari Argoud: KRAM IT! with Ari (KERIConf 2026) summary v0.1 — 2026-10-15: drafted by Claude from the curated transcript; unread by Mark; marked partner on Mark's word 2026-10-21, paraphrase only, no quotation partner 791 # Ari Argoud: KRAM IT! with Ari (KERIConf 2026) **Abstract.** Ari Argoud presented KRAM, the KERI (Key Event Receipt Infrastructure) Request Authentication Mechanism, which protects non-key-event messages against replay by checking that each message is both authentic and timely. The talk walked through the authentication types, the timeliness windows, the attacks that arise when those windows change, and the configuration for incremental adoption. It is aimed at implementers and operators of KERI v2 systems. ## Summary Argoud opened by defining KRAM as the authentication mechanism for every message in the KERI protocol that is not a key event: ESSR (encrypt sender, sign receiver) messages for secure APIs, which he described as a replacement for shared-secret account management, exchange messages for negotiating contracts, and credential presentations. The problem it solves is making sure a message is timely and authentic, so that an attacker who intercepts a valid signed message cannot replay it later. Each message carries a datetime stamp, and the receiver checks it against a window relative to its own clock; messages already seen or outside the window are dropped. KRAM sits at the top of the non-key-event processing pipeline, right after basic allow and deny filtering. It is designed for KERI v2, and it replaces an earlier approach of escrowing messages whose authentication data was missing with dropping them and notifying, so the sender's KEL (Key Event Log) can be fetched by a separate mechanism. After a short review of terms (AIDs, or autonomic identifiers; KELs; key state; SAIDs, or self-addressing identifiers, as digests of a message; and seals as cryptographic commitments anchored in a KEL), he described three authentication types: an anchoring seal reference, where the sender pre-authenticates a message by anchoring its digest in its own KEL; a single-key signature; and a multi-key signature. The type is resolved from key-list cardinality, and checks are ordered cheapest first to limit amplification and denial-of-service attacks. Multisig groups sign at different times and from different devices, so KRAM gives multi-key messages a long lag window, possibly minutes to days, while single-key and seal-reference messages get a short lag that covers only network latency and processing. He then explained replay attacks in general and the processing order: a cache lookup by SAID (allowing for multi-key messages that gather more signatures under the same SAID), a timeliness check for uncached messages based on the receiver's time, drift and the applicable lag, and then authentication, with threshold collection for multisig. Prune windows must always exceed accept windows. If the sender's key state changes during an exchange, the exchange has to start again. Two attacks arise from changing windows on a running system: gap replay, where a pruned message is replayed after the window grows, and gap first-play, where an intercepted message that never reached the receiver is played into a newly widened window. Decreasing a window is safe immediately; increasing one takes two steps, with a prune lag covering the difference between old and new windows; changing cache-type granularity needs worst-case analysis. The configuration supports incremental adoption: an enabled flag and deny lists keyed by KERI version, message type and route, with wildcards. In questions, participants discussed why a timestamp replaces an interactive nonce: it allows asynchronous messaging over any channel and avoids the extra round trips that add latency at scale. Argoud credited Samuel Smith with the white paper and the KERI Foundation with the implementation, and named IPEX exchange messages and healthKERI account communications as uses. ## Key terms KRAM, non-key-event messages, timeliness window, short lag, long lag, anchoring seal reference, key-list cardinality, gap replay attack, gap first-play attack, prune lag ## Claims and their evidence - KRAM orders its checks from cheapest to most expensive (cache lookup, timeliness, then authentication) to mitigate amplification and denial-of-service attacks. [informative] - Multi-key messages get a long lag window because group members sign at different times, while single-key and seal-reference messages get a short lag. [informative] - Prune windows must be greater than accept windows, and increasing a window requires a two-step change with a prune lag to prevent gap replay and gap first-play attacks. [informative] - Using the message time in place of a nonce allows non-interactive, asynchronous authentication without the extra network round trips of challenge-response. [informative] - KRAM targets KERI v2 and is being implemented by the KERI Foundation so that every deployment gets replay protection by default. [presenter-reported] ## Related KERI v2; ESSR, as covered in an earlier KERIConf 2026 talk by Philip Feairheller; the KRAM white paper by Samuel Smith; IPEX (Issuance and Presentation Exchange) messages; healthKERI. ## Provenance Drafted by Claude on 2026-10-15 from the curated transcript (02-ari-argoud-kram-it-with-ari.md), all of it (about 29 minutes of speech in a 37-minute recording). No quotations; paraphrase only. Not yet read by Mark.

Links from other tables