Network Working Group                                      Z. Eli
Internet-Draft                                                      draft-eli-z-protocol-00
Intended status: Experimental                              December 2025
Expires: 21 June 2026

    Z-Protocol: Zero-Handshake Adaptive Proof-of-Work
	       Encrypted Transport Protocol

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.


Abstract

   This document describes Z-Protocol, an experimental transport-layer
   protocol that establishes secure communication without a visible
   handshake.  Z-Protocol combines asymmetric cryptography, adaptive
   proof-of-work admission control, and stateless packet processing
   to mitigate denial-of-service attacks and reduce observable
   protocol metadata during connection establishment.


Table of Contents

   1.  Introduction
   2.  Design Goals
   3.  Threat Model
   4.  Protocol Overview
   5.  Client Packet Construction
   6.  Server Processing Model
   7.  Adaptive Proof-of-Work
   8.  Key Establishment
   9.  Replay Protection
   10. Transport Characteristics
   11. Deployment Considerations
   12. Compatibility Considerations
   13. Security Considerations
   14. IANA Considerations
   15. References


1.  Introduction

   Traditional secure transport protocols rely on explicit handshake
   exchanges to negotiate cryptographic parameters.  These handshakes
   introduce additional round trips and create protocol-visible
   metadata that may be observable by on-path entities.

   Z-Protocol explores an alternative approach in which the initial
   client packet simultaneously performs authentication, key
   establishment, and data transmission without a prior negotiation
   phase.


2.  Design Goals

   Z-Protocol is designed with the following goals:

   *  Eliminate explicit handshake round trips
   *  Provide early application data (0-RTT)
   *  Mitigate denial-of-service attacks at minimal server cost
   *  Remain compatible with existing public-key infrastructures
   *  Support hardware-assisted packet filtering


3.  Threat Model

   Z-Protocol assumes the presence of passive and active on-path
   attackers, including traffic observers and packet injectors.
   Compromise of trusted certification authorities is considered
   out of scope, consistent with existing TLS threat assumptions.


4.  Protocol Overview

   A Z-Protocol connection begins with a single client packet
   containing encrypted session material and an admission token.
   The server processes the packet statelessly and replies with
   encrypted application data and optional credentials.

   No cleartext handshake messages are exchanged.


5.  Client Packet Construction

   The client constructs an initial packet containing:

   *  A protocol identification marker
   *  A proof-of-work solution
   *  A compact root identifier hint
   *  An ephemeral session seed
   *  Optional application data

   All sensitive fields are encrypted using the server's public key.


6.  Server Processing Model

   Servers MAY deploy hardware or kernel-level filters to identify
   Z-Protocol packets based on the protocol marker.

   Packets failing proof-of-work validation SHOULD be discarded
   prior to allocation of application-layer resources.


7.  Adaptive Proof-of-Work

   Z-Protocol employs an adaptive proof-of-work mechanism to regulate
   client access under load.

   Servers MAY adjust acceptance thresholds dynamically.  Clients
   experiencing non-response SHOULD increase proof-of-work effort
   on subsequent attempts.


8.  Key Establishment

   The session seed contained in the initial packet is used to derive
   symmetric encryption keys.

   The seed MUST be unique per connection and MUST NOT be reused.


9.  Replay Protection

   Replay protection is achieved through a combination of ephemeral
   session seeds and server-side freshness checks.

   Replayed packets MUST be rejected.


10.  Transport Characteristics

   Z-Protocol operates over an unreliable transport such as UDP.
   Reliability, if required, is provided by the application layer.


11.  Deployment Considerations

   Z-Protocol is intended for controlled deployments and experimental
   evaluation.  It is not intended to replace TLS in general-purpose
   web traffic without further analysis.


12.  Compatibility Considerations

   Z-Protocol does not modify existing public-key infrastructures.
   Servers reuse existing certificate material for encryption.


13.  Security Considerations

13.1.  Forward Secrecy

   Z-Protocol provides forward secrecy by deriving symmetric keys
   from ephemeral session seeds.  Compromise of long-term keys does
   not expose past session data.

13.2.  Denial-of-Service Resistance

   Proof-of-work admission control limits asymmetric resource
   exhaustion and shifts computational cost to the initiating client.

13.3.  Replay and Injection Attacks

   Time-bound session material prevents successful replay of captured
   packets.

13.4.  Post-Quantum Considerations

   The protocol is compatible with post-quantum public-key algorithms,
   as the initial encryption mechanism can be replaced without
   altering packet structure.


14.  IANA Considerations

   This document does not require any IANA actions.


15.  References

15.1.  Normative References

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS)
              Protocol Version 1.3", RFC 8446, August 2018.

15.2.  Informative References

   [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
