Network Working Group Z. Eli Internet-Draft Independent Researcher Intended status: Experimental March 17, 2026 Expires: September 18, 2026 StealthFlow Protocol (SFP) draft-eli-stealthflow-protocol-01 Abstract This document specifies the StealthFlow Protocol (SFP), a pre-transport security layer designed to operate before TLS or QUIC. SFP introduces a zero-handshake mechanism with reduced observability and asymmetric cost properties to mitigate denial-of-service attacks and traffic analysis, while remaining compatible with existing PKI infrastructure. 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) 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. 1. Introduction Traditional TLS deployments expose identifiable handshake patterns (e.g., ClientHello, SNI, ALPN), which can be exploited by DPI systems and adversarial observers. Additionally, handshake asymmetry enables low-cost denial-of-service attacks. SFP addresses these issues by introducing: - A single-packet initiation model (zero handshake) - Proof-of-Work (PoW) based admission control - Low-observability packet structure - Compatibility with existing PKI and TLS SFP is not a replacement for TLS; it acts as a pre-layer. 2. Design Goals The protocol is designed with the following objectives: - Zero explicit negotiation (no handshake rounds) - Minimal network observability - Asymmetric cost enforcement (attacker > defender) - Compatibility with existing PKI - Fail-silent behavior - Strong integrity protection 3. Threat Model SFP assumes: - Advanced DPI and traffic analysis capabilities - Active probing and packet injection - High-concurrency denial-of-service attacks - Partial network manipulation Out of scope: - Fully compromised endpoints - Global PKI failure 4. Protocol Overview The client sends a single "armored" packet containing: - Dynamic guide identifier - Ephemeral public key - Proof-of-Work - Timestamp - Nonce - Packet hash - Signature - Random padding The server validates the packet statelessly and either: - Silently drops invalid traffic - Responds with a signed encrypted reply TLS or QUIC proceeds only after successful validation. 5. First Packet Format The first packet consists of: 1. Dynamic Guide Identifier (8–16 bytes) 2. Client Ephemeral Public Key (32 bytes, X25519) 3. Proof-of-Work: - SHA-256 hash with leading zeros ≥ D - Ed25519 signature (64 bytes) 4. Timestamp (8 bytes, millisecond precision) 5. Nonce (16–32 bytes) 6. Whole Packet Hash (32 bytes, SHA-256) 7. Signature (Ed25519 over all above fields) 8. Random Padding (0–256 bytes) 6. Proof-of-Work PoW is defined as: PoW = SHA256(IP || Timestamp || Nonce || C_eph_pub) Constraint: LeadingZeroBits(PoW) ≥ D Default difficulty: D = 20 bits The server MAY increase difficulty dynamically. Timestamp MUST fall within an acceptable window of server time. 7. Server Processing Upon receiving a packet: 1. Detect guide identifier 2. Extract client ephemeral public key 3. Verify signature 4. Verify packet hash 5. Validate PoW 6. Validate timestamp window 7. Optionally check Nonce uniqueness On failure: - Packet MUST be silently dropped On success: - Server generates a response 8. Response Packet The response contains: 1. Server Public Key (X25519, plaintext) 2. Encrypted Payload: - Certificate chain - Session parameters 3. Whole Response Hash (SHA-256) 4. Server Signature (Ed25519) Encryption uses a key derived via X25519. 9. Cryptographic Algorithms The following algorithms are REQUIRED: - Hash: SHA-256 - Signature: Ed25519 - Key exchange: X25519 - AEAD: ChaCha20-Poly1305 AES-128-GCM MAY be supported. 10. Security Properties SFP provides: - Resistance to traffic analysis - Cost asymmetry via Proof-of-Work - Replay protection via timestamp and nonce - Integrity via full-packet signatures - Mitigation of man-in-the-middle attacks via PKI 11. Integration with TLS/QUIC SFP operates as a pre-layer: - TLS handshake begins only after SFP success - QUIC MAY use SFP as a UDP pre-filter Existing TLS implementations require no modification. 12. Deployment Considerations Deployment can be incremental: - Internal infrastructure - Public APIs - High-value endpoints Hardware acceleration (e.g., XDP, eBPF, SmartNIC) is OPTIONAL. 13. Limitations - Does not hide IP addresses - Does not prevent endpoint compromise - Relies on existing PKI trust model - May be subject to long-term traffic analysis 14. IANA Considerations This document has no IANA actions. 15. Security Considerations Security is the primary focus of this protocol. Improper implementation of timestamp validation, nonce handling, or signature verification may weaken guarantees. 16. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Authors' Addresses Z. Eli Email: li.xiaoming@tutamail.com