Internet-Draft Z. Eli Intended Status: Experimental December 2025 Expires: June 2026 StealthFlow Protocol (SFP) draft-eli-stealthflow-protocol-00 Abstract The StealthFlow Protocol (SFP) is a low-observability, stateless pre-authentication and transport armor mechanism designed to precede existing TLS or QUIC sessions. SFP aims to reduce handshake fingerprinting, limit asymmetric denial-of-service amplification, and minimize early plaintext metadata exposure, while preserving compatibility with the existing PKI and TLS ecosystems. SFP does not replace TLS or QUIC. Instead, it provides an optional single-round pre-filtering and authentication layer that enables servers to reject illegitimate traffic with minimal computational cost and minimal network observability. This document supersedes the prior informal specification known as draft-eli-z-protocol-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 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. Table of Contents 1. Introduction 2. Design Goals 3. Protocol Overview 4. Packet Structure 5. Processing Model 6. Security Considerations 7. Privacy Considerations 8. IANA Considerations 9. Future Work 10. References Author's Address 1. Introduction Modern TLS and QUIC deployments expose observable handshake patterns early in the connection lifecycle. Even with encrypted handshakes, initial packets often reveal protocol versioning, structural fingerprints, and asymmetric cost characteristics exploitable for traffic analysis and denial-of-service attacks. In particular, attackers may generate large volumes of syntactically valid but unauthenticated initial packets at negligible cost, while forcing servers to perform comparatively expensive cryptographic or stateful operations. The StealthFlow Protocol (SFP) introduces a stateless, single-round pre-authentication mechanism that allows servers to cheaply discard unauthenticated traffic while minimizing protocol observability. SFP operates strictly before and outside of TLS or QUIC, and does not alter their cryptographic or transport semantics. 2. Design Goals SFP is designed with the following goals: * Minimize early observable protocol fingerprints. * Enable fail-silent rejection of unauthenticated traffic. * Impose symmetric or unfavorable economics on large-scale abuse. * Avoid introducing new trust anchors or modifying PKI behavior. * Remain compatible with existing TLS and QUIC implementations. * Allow stateless server-side processing at line rate. 3. Protocol Overview SFP consists of a single client-to-server packet, optionally followed by a single server response. The client sends an armored initial packet containing: * A fixed guide code identifying SFP traffic * A client-generated ephemeral public key * A proof-of-work (PoW) commitment bound to a freshness value * A whole-packet integrity hash * A digital signature covering all prior fields * Variable-length random padding Upon successful verification, the server MAY respond with a single packet containing encrypted session bootstrap information. Upon failure, the server silently discards the packet. No protocol negotiation, retransmission signaling, or persistent state is required. 4. Packet Structure 4.1. Client Initial Packet The client initial packet contains the following fields, in order: [Guide Code] [Client Ephemeral Public Key] [PoW Commitment] [Freshness Value] [Client Nonce] [Packet Hash] [Client Signature] [Random Padding] The Packet Hash MUST cover all preceding fields except padding. The Client Signature MUST cover the Packet Hash. 4.2. Server Response Packet If the server elects to respond, it sends: [Server Ephemeral Public Key] [Encrypted Payload] [Response Hash] [Server Signature] The Encrypted Payload is encrypted using the client ephemeral public key and contains the server certificate chain and session parameters necessary to bootstrap a subsequent TLS or QUIC connection. 5. Processing Model Server processing MUST prioritize inexpensive validation steps: 1. Verify the guide code. 2. Validate packet structure and length bounds. 3. Verify the packet hash and client signature. 4. Validate the PoW commitment. 5. Validate freshness within a configurable acceptance window. Packets failing any step MUST be silently discarded. Freshness validation SHOULD allow for network latency and clock skew. Typical deployments are expected to permit windows on the order of seconds rather than milliseconds. After successful validation, servers MAY proceed with TLS or QUIC session establishment using conventional mechanisms. 6. Security Considerations SFP reduces exposure to fingerprinting by avoiding explicit negotiation fields and minimizing deterministic structure in initial packets. Proof-of-work commitments increase the computational cost of large- scale abuse while remaining negligible for legitimate clients. Whole-packet signatures and hashes provide integrity protection against active manipulation. SFP does not protect against compromised endpoints, compromised PKI, or adversaries capable of global traffic correlation. 7. Privacy Considerations SFP is designed to minimize linkability across connections by using ephemeral keys and nonces. No stable client identifiers are exposed on the wire. Freshness values and PoW commitments MAY introduce coarse temporal correlation. Implementations SHOULD avoid excessively narrow acceptance windows to reduce unintended fingerprinting. Silent packet drops MAY still be observable through side channels such as timing or path MTU behavior. 8. IANA Considerations This document has no IANA actions. 9. Future Work Future revisions may include: * Formal wire encodings (e.g., CBOR) * Mandatory-to-implement cryptographic algorithms * Performance measurements and test vectors * Integration guidance for common TLS and QUIC stacks 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. 10.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. [RFC9000] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, May 2021. Author's Address Z. Eli Email: li.xiaoming@tutamail.com