Network Working Group Peavey Koding Internet-Draft Independent Researcher Intended status: Experimental January 21, 2026 Expires: July 21, 2026 Kaspa Kinesis Transport Protocol (KKTP) Threat Model draft-koding-kktp-threat-model-00 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." 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. Abstract This document defines the adversary model, security assumptions, security goals, and explicit non-goals for the Kaspa Kinesis Transport Protocol (KKTP). It describes the capabilities of potential attackers, the trust assumptions required for correct operation, and the limits of the protocol's security guarantees. This document is intended to complement the main KKTP specification. 1. KKTP Threat Model This document defines the adversary model, security goals, non-goals, and trust assumptions for the Kaspa Key Transport Protocol (KKTP). It is intended to be referenced from the main specification. 2. Adversary Capabilities KKTP is designed under the assumption of a powerful adversary with the following capabilities: - Global Observation The adversary MAY observe all Kaspa transactions, including anchors, mailbox messages, public keys, SIDs, mailbox identifiers, timestamps, and transaction ordering. - Active Network Participation The adversary MAY submit arbitrary Kaspa transactions, including malformed or malicious KKTP payloads, and MAY attempt to flood mailboxes subject to transaction fee costs. - Message Reordering and Delay Due to the BlockDAG structure, the adversary MAY influence message arrival order and MAY delay message inclusion, but CANNOT selectively suppress transactions once accepted by the network without incurring economic cost. - Replay Attempts The adversary MAY replay previously observed valid KKTP messages. - Key Compromise (Limited) The adversary MAY compromise long-term signing keys or ephemeral session keys after a session has completed, but is assumed NOT to compromise both parties' ephemeral DH private keys during an active session. - No Cryptographic Breaks The adversary is assumed NOT to break standard cryptographic primitives (X25519, Ed25519, XChaCha20-Poly1305, BLAKE2b, HKDF). 3. Security Goals (In Scope) KKTP provides the following guarantees against the adversary described above: - Confidentiality Message contents are confidential to session participants. Observers cannot recover plaintext without access to the session key. - Integrity and Authenticity Message tampering, forgery, or bit-flipping is detected via AEAD authentication tags. - Replay Protection Replayed messages are detected and rejected via strict per-direction sequence enforcement. - Session Binding Messages are cryptographically bound to a specific session via mailbox identifiers, session identifiers (SID), and key agreement material. - Public Verifiability Any observer can verify that a session was established between specific public keys and that observed messages are attributable to that session. - Forward Secrecy Compromise of long-term signing keys does not compromise past session contents, provided ephemeral DH keys were securely erased. 4. Explicit Non-Goals (Out of Scope) KKTP explicitly does not attempt to provide the following properties: - Cryptographic Deniability Session establishment is signed and publicly anchored. Participants cannot plausibly deny session participation after the fact. - Metadata Privacy Traffic patterns, message timing, mailbox identifiers, and session existence are visible on-chain. - Anonymity KKTP does not hide the relationship between public keys and sessions. Anonymity requires external measures such as ephemeral identities or network-level privacy systems. - Guaranteed Delivery KKTP provides ordered, authenticated messaging if messages are observed, but does not guarantee delivery in the presence of sustained censorship, reorganization, or fee exhaustion. - Endpoint Compromise Resistance KKTP does not protect against malware, key exfiltration, or malicious behavior on compromised endpoints. 5. Man-in-the-Middle (MITM) Considerations - KKTP prevents passive MITM attacks through authenticated key agreement and AEAD encryption. - Active MITM attacks are detectable through signature verification and session binding. - Full resistance to active MITM attacks requires trusted public keys or out-of-band verification. - Optional VRF binding strengthens detection of key substitution, replay, and backdating attacks but does not replace identity authentication. 6. Denial-of-Service (DoS) Considerations - KKTP is subject to DoS attempts via mailbox flooding. - Kaspa transaction fees impose an economic cost on large-scale flooding attacks. - Implementations MUST perform AEAD authentication checks before allocating significant memory or performing expensive processing. - Implementations MUST enforce strict bounds on out-of-order message buffering. 7. Key Compromise Scenarios - Compromise of Long-Term Signing Keys Enables impersonation in future sessions but does not compromise confidentiality of past sessions. - Compromise of Ephemeral DH Keys During an Active Session Compromises confidentiality for that session only. - Compromise After Session Termination Does not compromise past session confidentiality if ephemeral keys were securely erased. 8. Trust Assumptions KKTP assumes: - Correct implementation of cryptographic primitives. - Secure random number generation. - Proper key erasure by implementations. - Correct enforcement of Kaspa consensus rules. Violation of these assumptions may weaken or invalidate the stated security guarantees. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References None. 10.2. Informative References [KKTP] Peavey2787, "Kaspa Kinesis Transport Protocol (KKTP)", draft-peavey-kktp-00, January 2026. Author's Address Peavey Koding Independent Researcher Email: peavey2787@yahoo.com GitHub: https://github.com/peavey2787