DPA R&D Ltd (https://www.dpa-cloud.co.uk)

b.fisher@dpa-cloud.co.uk https://orcid.org/0009-0004-4412-2269

Security UZP zero-port identity rendezvous transport AEAD The Universal Zero-Port Transport Protocol (UZP) defines an identity-addressed, encrypted-by-default transport for the Universal Zero-Port Interconnect Framework (UZPIF; ). Instead of exposing IP:port listeners, both endpoints establish outbound, identity-bound sessions to one or more Rendezvous Nodes (RNs). The RN performs flow stitching but never terminates end-to-end cryptography or holds long-term secrets. All application data is carried over an authenticated encryption (AEAD) channel keyed by a handshake based on modern and post-quantum-capable primitives. Reliability is expressed at the block level, rather than at the TCP segment or stream level, enabling selective retransmission and deterministic pacing. This document specifies the UZP wire format, handshake, cryptographic negotiation, exporter interface, 0-RTT rules, replay model, and RN behaviour, and its relationship to UZPIF (), QUIC (), HIP (), and TLS 1.3 (). This document is an Internet-Draft derived from internal research material solely to enable structured technical review, interoperability discussion, and disciplined specification development under the Internet-Draft process. It is a work-in-progress research artefact and does not constitute a standard, recommendation, or finished specification. The text aims to preserve a clear separation of normative and informative content. Requirement words are used only where protocol behaviour is intentionally specified. Where this document provides numeric guidance (for example timers, windows, or congestion-related tuning), the intent is to offer recommended bounds suitable for experimentation; profile-based behaviour and implementation discretion are explicitly expected within stated limits. UZP is designed for identity-first, zero-port environments where conventional port-based transport assumptions do not hold; it is not presented as a universal replacement for existing transports.

Scope and Status This Internet-Draft describes UZP as an experimental transport protocol for the Universal Zero-Port Interconnect Framework (UZPIF; ). The intent is to support early peer review and implementation experiments; substantial revision is expected. Unless otherwise stated, design parameters and numeric values are provided as numeric guidance and recommended bounds, rather than as fixed constants. Implementations may adopt alternative congestion tuning, profile-based behaviour, and implementation-defined choices within the constraints explicitly described in the relevant sections. It is not a universal replacement, is not mandated outside its target environment, and is designed for experimentation and profile-driven deployments.

Introduction The deployed Internet largely continues to rely on listening sockets bound to IP:port tuples. This design, inherited from the 1980s, exposes every reachable service to scanning, unsolicited ingress, and a wide class of lateral-movement and amplification attacks. Contemporary defences such as WAFs, DDoS scrubbing, layered ACLs, and micro-segmentation treat the symptom, not the cause. The Universal Zero-Port Interconnect Framework (UZPIF; ) proposes a post-port architecture in which services are reached only via outbound, identity-bound connections to Rendezvous Nodes (RNs). UZP is the transport protocol that operates beneath UZPIF () and is designed for identity-first, zero-port environments where conventional port-listening assumptions do not hold. In that context, it provides transport and security semantics comparable to conventional TCP+TLS or QUIC+TLS data planes, while keeping legacy applications unmodified above a Host Identity Layer (HIL). The design builds on ideas from QUIC , HIP , and Zero Trust Architecture . Rendezvous-based systems such as Tor demonstrate the value of decoupling endpoint identity from network location. UZP is intended to be compatible with post-quantum cryptography profiles .

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in and when, and only when, they appear in all capitals, as shown here. This document uses terminology from UZPIF () and related work:

• Endpoint (EP): A host participating in UZP communication. EPs never listen on public IP:port tuples.
• Rendezvous Node (RN): A relay node that accepts outbound connections from EPs, validates Pantheon-issued Grants, and stitches identity-bound flows.
• Pantheon: The global identity, attestation, and policy plane used by UZPIF () and UZP.
• Canonical Identity (CID): A long-lived, cryptographic identifier derived from a principal's public signing key.
• Ephemeral Identity (EID): A per-session identity bound to short-lived key material.
• Block: The unit of reliability (acknowledgement / retransmission) in UZP.
• Frame: The unit of application payload mapping inside a block.

Design Goals UZP is intended to satisfy the following primary goals:

• Zero exposed ports: EPs MUST operate with no listening sockets reachable from the public Internet. All communication originates from outbound connections to RNs.
• Identity-first addressing: The fundamental addressing object is a cryptographic identity (CID/EID), not an IP:port pair, following the spirit of HIP .
• Encrypted-by-default: All application data MUST be carried over an AEAD-protected channel, with forward secrecy and exporter support comparable to TLS 1.3 .
• Modern and PQ-capable: The handshake MUST support both classical and post-quantum key exchange and authentication, with algorithm agility and central policy control .
• Block-level reliability: Reliability is expressed at the block level, enabling selective retransmission and deterministic pacing similar in spirit to, but distinct from, QUIC's stream framing .
• RN minimal trust: RNs MUST NOT learn application plaintext or hold long-term identity secrets; they may only drop, reorder, or delay encrypted traffic.

Where this document provides numeric guidance (for example, congestion-related tuning, replay windows, or pacing), it is intended as recommended bounds for experimentation. Implementations may apply profile-based behaviour and implementation-defined tuning within any explicit limits stated in the relevant sections.

Architectural Overview At a high level, UZP operates as follows:

1. Each EP opens one or more outbound control channels to one or more RNs.
2. The EP authenticates to Pantheon and obtains Grants that authorise communication with a peer identity under specific policy.
3. To talk to another EP, the initiator submits a Join request to an RN, containing its own CID/EID, the target CID, and the relevant Grant material.
4. The responder independently connects to an RN (which MAY be the same RN or a different RN in the same trust domain) and presents its own Grants.
5. The RN stitches the two UZP sessions into a zero-port interconnect tunnel (ZPIT) once both sides have been validated.

The RN never terminates end-to-end cryptography; each side performs a UZP handshake with the RN, derives end-to-end keys using exporter material, and then switches to E2E AEAD for application data.

High-Level Session Flow

High-level communication pattern: both endpoints initiate outbound-only connections to the RN, which stitches an end-to-end ZPIT. EP_I (Initiator) RN EP_R (Responder) |-- outbound ctl/data -->|<-- outbound ctl/data --| |<==== E2E AEAD over ZPIT (via RN) ====>|

This figure shows both endpoints initiating outbound sessions to the RN, which stitches them into a ZPIT.

Identity Model and CID Stability Pantheon issues long-term signing keys to principals; the canonical identity CID is defined as a hash (e.g., BLAKE3) of the public signing key. CIDs are intended to be stable over multi-year time scales and across multiple devices in the same administrative entity, and SHOULD only change when the underlying key is rotated or revoked due to compromise. Each transport session also has an Ephemeral Identity (EID), derived from short-lived key material. EIDs are bound to CIDs via Pantheon-issued credentials and are used within the UZP handshake and record layer. This separation mirrors the long-term vs. ephemeral key split in both HIP and TLS 1.3 .

Handshake Overview The UZP handshake provides:

• Mutual (or unilateral) authentication bound to CIDs and EIDs.
• Negotiation of cipher suites and AEAD algorithms.
• Derivation of exporter keys for UZPIF () and higher layers.
• Integration of Pantheon Grants, including replay protection and policy binding.

The RN forwards handshake messages but does not terminate the cryptographic handshake itself. Instead, both EPs derive end-to-end secrets using exporter material bound to the identities and Grants, and then switch to direct AEAD protection across the ZPIT.

Flight Diagram Figure sketches a representative two-party handshake mediated by an RN. Exact messages and encoding are defined in the wire-format section (not reproduced in full here).

Example UZP handshake flights via an RN. Message indices [1]-[6] are explained in the legend. Labels are illustrative; exact message contents are defined in the wire specification. | | |--[2] CH1' (fwd) -->| | |<-[3] SH, EE, CERT_R, FIN_R--| |<-[4] SH', EE', CERT'_R, FIN'_R ----| |--[5] Finished_I ------------------->| | |--[6] Finished'_I --->| ]]>

This figure summarizes the RN-relayed handshake flights and where forwarding occurs. Legend:

[1]

CH1: ClientHello_I, EID_I, Grant

[2]

CH1': Forwarded ClientHello_I

[3]

SH, EE, CERT_R, FIN_R

[4]

SH', EE', CERT'_R, FIN'_R

[5]

Finished_I (initiator final confirm towards RN)

[6]

Finished'_I (forwarded initiator confirm towards responder)

Cryptographic Negotiation and AEAD Tag Length UZP supports an extensible cipher-suite registry. A cipher suite includes:

• A key exchange mechanism (e.g., X25519, or a PQ KEM candidate).
• A signature algorithm for authentication.
• An AEAD algorithm for record protection (e.g., AES-GCM-128, ChaCha20-Poly1305).
• A KDF (e.g., HKDF-SHA256 or a BLAKE3-based KDF).

AEAD Tag Length The AEAD tag length is algorithm-dependent but subject to the following constraints:

• Implementations MUST use a tag length of at least 96 bits for all UZP application data records.
• When an AEAD algorithm allows variable tag lengths, endpoints SHOULD use the algorithm's full tag length (typically 128 bits for AES-GCM) and MUST NOT negotiate a tag length below 96 bits.
• The tag length used for a session is fixed for the lifetime of that session and is implied by the negotiated cipher suite.

This requirement follows common practice in modern protocols, which treat 96 bits as a practical lower bound on AEAD authentication tags for wide-area deployments, while allowing future AEADs with different native tag lengths.

Blocks, Frames, and Reliability UZP uses a block-oriented reliability model:

• A block is a unit of transmission and acknowledgement.
• Each block contains one or more frames, which carry application data or control information.
• Blocks carry monotonically increasing block numbers, and ACK frames reference blocks, not individual bytes.

This block-level model enables selective retransmission and deterministic pacing:

• EPs can rapidly detect loss patterns and retransmit only affected blocks.
• Congestion control and pacing can be applied over well-defined block units, similarly to how QUIC applies logic over packet and frame boundaries .

Blocks are encrypted and authenticated with the negotiated AEAD. The associated data includes:

• CID and EID for both parties.
• Direction and block number.
• A context-specific label (e.g., "uzp-application" or "uzp-handshake").

Exporters UZP defines an exporter interface analogous to TLS exporters . Exporters derive context-specific keys from the main handshake secrets, using labels and context values that MUST be bound to identities and transport parameters. An exporter input consists of:

• A label (e.g., "uzpif-zpit-key").
• A context value (which may include CIDs, EIDs, RN identifiers, and Grant nonces).
• An output length.

Exported keys are used by:

• UZPIF () to derive per-ZPIT keys for monitoring or additional encapsulation.
• Higher-layer protocols wishing to bind application security directly to UZP session properties.

Exporters MUST incorporate both CIDs and the negotiated transport parameters so that re-use of exporters across sessions is cryptographically separated.

0-RTT Data and Replay Handling UZP allows, but tightly constrains, 0-RTT (early) data:

• Early data MAY be sent by a client that possesses a valid, non-expired session resumption token and a Pantheon Grant that explicitly permits early data.
• Early data MUST be cryptographically distinct from 1-RTT data and MUST be bound to a monotonically increasing Grant nonce.
• RNs MUST treat 0-RTT flows as replayable at the transport level and MUST NOT rely on transport-layer properties for replay prevention.

Replay prevention is handled jointly by:

• Pantheon Grants, which include a Grant nonce and time window; replayed Grants outside their window MUST be rejected.
• Endpoints, which track nonces and session tickets, and MUST refuse to process 0-RTT requests that would not be safe to replay at the application level.

If Pantheon policy specifies "no-replay" for a given Grant, endpoints MUST NOT use 0-RTT for any traffic under that Grant, and RNs MUST drop any early data tagged with that policy.

Post-Quantum Profiles and Crypto Agility Given the long-term horizon of identity-centric networking, UZP is designed to support post-quantum (PQ) algorithms:

• Cipher suites define both classical and PQ-capable KEMs and signature schemes.
• Pantheon policy can enforce that certain tenants or epochs require PQ-only or hybrid key exchange.
• The handshake format allows negotiation of PQ suites in parallel with classical ones, similar to ongoing PQ-TLS efforts .

Transport endpoints SHOULD support at least one PQ KEM and one PQ-capable signature algorithm as they become standardised.

Rendezvous Node Behaviour RNs are designed to be minimally trusted intermediaries. An RN:

• Accepts outbound connections from EPs and validates their Pantheon-issued credentials and Grants.
• Matches Join requests between EPs and stitches them into ZPITs according to policy.
• Relays encrypted blocks between stitched endpoints, potentially applying rate limits, traffic shaping, and policy enforcement on encrypted metadata.

Importantly, an RN:

• MUST NOT terminate end-to-end UZP AEAD protection.
• MUST NOT hold long-term secrets for EP identities.
• MAY observe and act on limited metadata (e.g., CIDs, block counts, timing) comparable to the exposure in QUIC's on-path model .

For high-assurance deployments, multi-RN topologies similar to onion routing may be used , with attestation chains that prove that each RN conforms to specified software and configuration baselines.

Security Considerations UZP's security properties derive from:

• The zero-port architecture of UZPIF () (no open listeners).
• The use of modern AEAD algorithms with at least 96-bit tags.
• Identity-first addressing via CIDs and EIDs, influenced by HIP .
• Exporters that bind higher-layer security directly to transport identities and parameters.
• Strong replay controls via Grants and endpoint tracking of nonces and tickets.

Residual risks include traffic analysis, RN compromise (drop/delay behaviour), and application-layer weaknesses. These are mitigated through:

• Multi-RN topologies and attestation.
• Pantheon policy that can revoke identities and Grants quickly.
• Integration with Zero Trust principles .

IANA Considerations This document makes no requests of IANA at this time. Future revisions of UZP may define registries for protocol parameters (for example cipher suites, frame types, and exporter labels), but such actions are out of scope for this introductory specification.

• A registry for UZP cipher suites and AEAD algorithms.
• A registry for frame and block types.
• A registry for exporter labels used by UZP and UZPIF ().

Normative References Informative References

Acknowledgements The author thanks colleagues and early reviewers for discussions on identity-centric networking, rendezvous transports, and post-quantum transition considerations. Any errors or omissions remain the author's responsibility.