TLS-DPA: An Identity-Bound Security Protocol for Traditional, Overlay, and Zero-Port Transports

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."¶

This Internet-Draft will expire on 17 September 2026.¶

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.¶

Table of Contents

1. Scope and Status

This Internet-Draft is part of an experimental, research-oriented suite prepared for the Independent Stream. It specifies TLS-DPA for identity-first and topology-independent deployments, including rendezvous and zero-port fabrics, while remaining open to substantial revision through review and implementation experiments.¶

Within that suite, this document defines the current normative baseline for trust objects, validation rules, and security semantics within TLS-DPA, especially identity binding, transcript construction, and handshake authorisation. Hard interoperability is expected for shared object semantics and validation rules.¶

Full wire-level, clustering, and proof-family interoperability is not claimed everywhere yet; the remaining details are intentionally profile-defined or deferred, so this draft should not be read as claiming a fully closed wire image or proof model.¶

TLS-DPA is designed for environments where conventional port-listening assumptions and IP:port-based identity binding do not hold. It is designed for experimentation and profile-driven deployments within its target environment. Privacy, decentralisation, and availability remain deployment- and profile-dependent properties.¶

2. Introduction

TLS 1.3 ( [RFC8446] ) defines the current baseline for transport-layer security on the Internet. However, its usage patterns remain oriented around server-side listeners bound to IP address and port tuples, and many deployments treat these network coordinates as meaningful anchors for authentication and policy.¶

TLS-DPA extends the design principles of TLS 1.3 to support:¶

• operation over identity-first, topology-independent transports (for example UZP; [UZP] );¶

• authentication bound to Service Identities, rather than IP addresses and ports;¶

• reduced metadata exposure to intermediaries, including rendezvous nodes in UZP fabrics;¶

• hybrid classical/post-quantum KEM negotiation aligned with the NIST PQC process ( [NIST-PQC] );¶

• session continuity across transport or overlay path changes (for example QUIC Connection IDs; [RFC9000] ).¶

The eventual TLS-DPA wire image is intended to remain close to TLS 1.3, enabling reuse of existing implementation structure while adding explicit identity and transport binding into the handshake transcript and key schedule. This draft does not yet close every byte-level encoding, extension layout, or deployment profile.¶

TLS-DPA also aligns with zero-trust guidance (NIST SP 800-207 [NIST-SP800-207]) and identity-centric designs such as HIP [RFC7401].¶

This draft should therefore be read as part of an experimental, research-oriented Independent Stream suite and as the current normative baseline for trust objects, validation rules, and security semantics within TLS-DPA. Hard interoperability is expected for shared object semantics and validation rules. Full wire-level, clustering, and proof-family interoperability is not claimed everywhere yet; the remaining details are intentionally profile-defined or deferred. Reducing metadata exposure in some roles does not imply complete privacy or invisibility, and rendezvous or clustered deployment availability still depends on explicit operational choices.¶

3. Layering and Interoperability Baseline

This document is organised into four specification strata: core handshake semantics; transport binding rules; UZP / UZPIF applicability and profile rules; and optional or experimental extensions. The intent is to keep the core handshake and trust story stable even where exact extension code points, deployment profiles, or transport-specific optimisations remain open.¶

Sections Section 6, Section 8, Section 9, Section 10, Section 11, Section 13, Section 14, Section 16, and Section 17 define the core handshake semantics and trust decisions required for baseline interoperability. Sections Section 7 and Section 12 define the transport binding rules that feed those semantics. Sections Section 18 and Section 19 define the UZP / UZPIF applicability profile. Section Section 20 is outside baseline interoperability unless a later profile explicitly upgrades it.¶

Baseline interoperable behaviour in this revision requires the core semantics for Service Identity binding, transcript construction, key schedule inputs, minimum revocation processing, Service Identity validation, and alert handling. Baseline interoperable transport binding further requires processing of tlsdpa_service_identity and tlsdpa_transport_binding. The tlsdpa_pq_kem_params extension is required when a negotiated deployment profile enables post-quantum or hybrid KEM operation.¶

Exact extension code points, final wire encodings, some revocation acquisition paths beyond the baseline processing rules, UZP early-data and rebind policy, and optional attribution metadata remain profile-dependent or experimental in this revision. Optional extensions MUST NOT alter authentication, authorisation, or trust outcomes unless a later profile explicitly upgrades them.¶

Sections Section 5, Section 15, Section 21, and Section 22 are explanatory or deployment-oriented unless they explicitly restate a normative baseline rule from the sections above.¶

4. 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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Terminology used throughout this document:¶

CID

Canonical Identity (a long-term public key hash).¶

EID

Ephemeral Identity (a session-level fingerprint).¶

UZP

Zero-port transport as defined by the companion UZP Internet-Draft ( [UZP] ).¶

ZPIT

Zero-Port Interconnect Tunnel (a UZP fabric channel).¶

Pantheon

A federated or deployment-scoped identity, attestation, and policy plane whose authorities bind identity, policy, and trust metadata to keys or selectors accepted under local policy, may validate or certify those bindings, and may issue credentials, Grants, and delegations over them.¶

Service Identity

The identity to which TLS-DPA authentication is bound (for example a DNS name, CID, EID, or a UZPIF selector).¶

Specification-Origin Identifier

An OPTIONAL non-authoritative attribution metadata field carried by extension.¶

5. Design Goals

TLS-DPA is designed to:¶

1. decouple channel authentication from IP address and port topology;¶

2. provide identity-first naming independent of network routing;¶

3. support hybrid classical and post-quantum KEM negotiation aligned with NIST PQC guidance ( [NIST-PQC] );¶

4. reduce metadata in early handshake flights;¶

5. bind channels to transport-level identifiers (for example UZP SessionIDs or QUIC Connection IDs; [RFC9000] );¶

6. remain closely aligned with the structure of TLS 1.3 ( [RFC8446] );¶

7. operate efficiently over UZP and UZPIF rendezvous fabrics ( [UZP] , [UZPIF] ).¶

Where this document specifies algorithms or parameter sets (for example hybrid KEM combinations), these are intended as recommended profiles and may evolve. Implementations may support additional profiles and apply implementation-defined choices within any explicit limits described in the relevant sections.¶

6. Core TLS-DPA Semantics

TLS-DPA retains the basic architecture of TLS 1.3 ( [RFC8446] ) but introduces:¶

• transport-agnostic channel binding, via a dedicated extension that carries a transport identifier and class;¶

• Service Identity negotiation and binding into the transcript;¶

• mandatory transcript binding of identity and transport metadata;¶

• PQ-ready hybrid KEM negotiation using an explicit parameter extension;¶

• stable session resumption across topology or path changes.¶

TLS-DPA defines the handshake over an abstract TLS-DPA Channel. The channel only needs to provide:¶

• ordered or reliably framed delivery;¶

• a transport-level identifier (e.g., a TCP 4-tuple, QUIC Connection ID; [RFC9000] , or a UZP SessionID);¶

• uniqueness sufficient for transcript binding.¶

Together with Sections Section 8, Section 9, Section 10, Section 11, Section 13, Section 14, Section 16, and Section 17, this section defines the core TLS-DPA handshake semantics for baseline interoperability.¶

7. Transport Binding Rules

This section and Section Section 12 define the transport binding rules consumed by the core TLS-DPA handshake. Baseline interoperability requires consistent construction and verification of Service Identity and transport-binding inputs; exact code points and final byte-level encodings remain profile-defined in this revision.¶

TLS-DPA treats the underlying transport as providing one or more channels:¶

• TCP : traditional byte stream;¶

• QUIC : stream over a QUIC connection, identified by QUIC Connection ID ( [RFC9000] );¶

• UZP : stream inside a ZPIT, identified by a UZP SessionID ( [UZP] ).¶

The handshake binds to this transport using the tlsdpa_transport_binding extension (see Section 12.2 ).¶

+------------+   +---------------+   +------------+
| TLS-DPA    |-->| Transport     |-->| TLS-DPA    |
| Client     |   | Channel       |   | Server     |
| Handshake  |   | Handshake &   |   |            |
| Protected  |   | Protected     |   |            |
| Data       |   | Data          |   |            |
+------------+   +---------------+   +------------+

This figure places TLS-DPA above a transport channel to highlight the separation from the underlying relay.¶

8. Identity Binding Model

TLS-DPA authenticates peers using Service Identities, which may be:¶

• DNS names (validated per RFC 6125).¶

• UZP CIDs (canonical identities, derived from long-term public keys).¶

• UZP EIDs (ephemeral, session-level identities).¶

• UZPIF selectors resolved via Pantheon services, federated identity services, or local trust mappings [UZPIF].¶

The Service Identity MUST be included in the handshake transcript and validated as described in Section Section 16.¶

CIDs are intended to be stable over meaningful operational time-scales: changes in CID MUST be treated as key-rotation events and not as transient transport artefacts.¶

9. Identity Authority and Trust Model

TLS-DPA identity issuance is intentionally decentralisable. Service Identity credentials MAY be self-issued, multi-signed, federation-signed, or organisationally issued. Deployments MAY use one or more issuance models concurrently.¶

Where Pantheon is used in a UZPIF-aligned deployment, Pantheon authorities bind identity, policy, and trust metadata to keys or selectors accepted under policy; they may validate or certify those bindings and issue credentials, Grants, or delegations over them, but they need not generate or custody the underlying private keys.¶

TLS-DPA implementations MUST NOT require a single global signing authority. The protocol does not mandate a central certificate authority.¶

If any root trust model is used by a deployment profile, that model MUST be replaceable without protocol redesign.¶

10. Post-Quantum Key Exchange Model

TLS-DPA introduces unified hybrid-KEM negotiation via the tlsdpa_pq_kem_params extension. Supported KEM schemes include:¶

• X25519 (classical ECDH).¶

• Kyber768 (PQC KEM candidate).¶

• A hybrid X25519+Kyber768 mode.¶

The key schedule incorporates PQ KEM inputs prior to traffic secret derivation, following general design principles for hybrid KEMs in the NIST PQC process [NIST-PQC].¶

11. Key Schedule Summary

TLS-DPA modifies the TLS 1.3 key derivation [RFC8446] to include:¶

• Service Identity.¶

• Transport Binding.¶

• PQ KEM materials.¶

Exporter values MUST be bound to both identity and transport (Section Section 14).¶

At a high level, PQ hybrid KEM inputs augment the TLS 1.3 key schedule:¶

shared_secret = HKDF-Extract(kem_secret || ecdh_secret)

This equation shows the hybrid extraction step that combines KEM and ECDH inputs.¶

AEAD algorithms used with TLS-DPA MUST follow their specification-defined tag lengths. Tags MUST NOT be truncated below 96 bits, and 128-bit tags SHOULD be preferred where supported.¶

12. Transport Binding Extensions

This section carries the handshake extensions that bind the core TLS-DPA semantics into the transcript. Baseline interoperable behaviour requires tlsdpa_service_identity and tlsdpa_transport_binding. The tlsdpa_pq_kem_params extension is required when a negotiated deployment profile enables post-quantum or hybrid KEM operation.¶

The extension semantics in this section are normative where baseline interoperability requires them, but the example code points and C-like structures are illustrative and intended for experimentation. This draft does not request IANA allocations. Where appropriate, implementations may use private-use ranges or negotiated profiles while preserving the semantics defined here.¶

extension_type = 0xFE01

struct {
    ServiceIdentityType identity_type;
    opaque identity_value<1..2^16-1>;
} ServiceIdentity;

enum {
    dns_name(0),
    uzp_cid(1),
    uzp_eid(2),
    uzpif_selector(3),
    (255)
} ServiceIdentityType;

extension_type = 0xFE02

struct {
    opaque transport_id<1..32>;
    uint8  transport_class;   /* 0=TCP, 1=QUIC, 2=UZP */
    opaque transport_params<0..256>;
} TransportBinding;

extension_type = 0xFE03

struct {
    KEMScheme kem_list<2..2^8-1>;
} PQKemParams;

enum {
    x25519(0),
    kyber768(1),
    hybrid_x25519_kyber768(2),
    (255)
} KEMScheme;

13. Transcript Hashing Rules

New transcript components MUST be inserted as follows:¶

th = Hash(ClientHello
          || ServiceIdentity
          || TransportBinding
          || PQKemParams
          || ServerHello
          || ... )

This figure shows where the new identity and transport inputs are inserted into the transcript hash.¶

Hash mismatches MUST abort the handshake with illegal_transport_binding or identity_mismatch (Section Section 17).¶

14. Key Schedule and Exporters

PQ hybrid KEM inputs augment the TLS 1.3 key schedule as:¶

shared_secret = HKDF-Extract(kem_secret || ecdh_secret)

This figure shows the shared secret input used for exporter derivation.¶

Exporter keys MUST incorporate identity and transport bindings.¶

label = "tlsdpa exporter" || 0x00 ||
  identity_type || transport_class

struct {
    opaque sid_hash[32];      /* BLAKE3-256 of Service Identity */
    opaque tb_hash[32];       /* BLAKE3-256 of TransportBinding */
    opaque kem_id[1];         /* selected KEM scheme */
} ExporterContext;

shared = HKDF-Extract(kem_secret || ecdh_secret);
ctx = ExporterContext(sid_hash, tb_hash, kem_id);
key = HKDF-Expand(shared, label, ctx, outlen);

15. Handshake Diagrams

EP-Client             RN                EP-Server
    |                 |                      |
    |---- CH1: ClientHello(SID,TB,PQ) ------>|                      |
    |                 |--- CH1' (fwd) ----------------------------->|
    |                 |<-- SH1: ServerHello(PQ,TB) -----------------|
    |<--- SH1' (fwd) -|                      |
    |---- CH2: EncryptedExtensions --------->|                      |
    |                 |--- CH2' (fwd) ----------------------------->|
    |                 |<-- EE2/Cert/Finished -----------------------|
    |<--- EE2'/Cert'/Finished' --------------|                      |
    |<==== Finished + Encrypted App Data ===>|

Client          Transport Layer          Server
  |-- ClientHello(SID) -->|                    |
  |                       |-- CH fwd --------->|
  |                       |<-- ServerHello ----|
  |<-- ServerHello -------|                    |
  |-- EncryptedExtensions>|                    |
  |<-- Certificate, Finished ------------------|
  |-- Finished / App Data -------------------->|

16. Service Identity Validation

17. New Alerts

TLS-DPA defines the following experimental alert descriptions for use in deployments and interoperability testing. The numeric values shown are illustrative and are not requested for IANA allocation by this draft.¶

enum {
    illegal_transport_binding(200),
    identity_mismatch(201),
    pq_required(202),
    grant_invalid(203),
    grant_expired(204),
    (255)
} AlertDescription;

This figure lists the experimental alert codes defined by TLS-DPA.¶

18. UZP / UZPIF Applicability and Profile

This section defines the UZP / UZPIF profile for TLS-DPA. It is required only for deployments that carry TLS-DPA over UZP or consume UZPIF trust artefacts; it does not redefine the core handshake semantics.¶

TLS-DPA maps naturally to UZP by binding:¶

• tlsdpa_service_identity -> UZP CID/EID.¶

• tlsdpa_transport_binding -> UZP SessionID.¶

• PQ capability and fallback -> Pantheon Grants.¶

UZP's multi-step rendezvous and authentication model, together with the UZPIF framework defined in [UZP] and [UZPIF], provides:¶

• stronger pre-TLS identity establishment;¶

• reduced man-in-the-middle risk;¶

• deterministic channel binding for TLS-DPA.¶

This section and Section Section 19 are normative only for deployments that carry TLS-DPA over UZP or consume UZPIF trust artefacts. They do not redefine the core handshake semantics; they constrain how those semantics are applied in zero-port fabrics.¶

19. Early Data (0-RTT)

Over UZP:¶

• early data is transmitted inside a ZPIT;¶

• replay protection uses CID/EID and Pantheon Grant metadata;¶

• early data MUST NOT be used if Pantheon Grants specify "no-replay".¶

grant_nonce || CID || EID || SessionID

(grant_nonce, CID, EID, ticket_age)

20. Optional and Experimental Extensions

The extensions in this section are not required for baseline interoperability. They MUST NOT alter authentication, authorisation, transcript truth, or trust-anchor decisions unless a later deployment profile explicitly upgrades them.¶

extension_type = 0xFE04

struct {
    opaque origin_id<1..255>;
    opaque origin_uri<0..1024>;
} SpecificationOriginIdentifier;

21. Threat Model

TLS-DPA is designed to defend against:¶

• passive eavesdropping;¶

• active man-in-the-middle;¶

• downgrade attacks on both classical and PQ negotiation;¶

• identity spoofing;¶

• transport reattachment and rebinding attacks across overlays.¶

In UZP deployments, RN visibility is expected to be limited primarily to flow identifiers, relay context, and encrypted envelopes. Plaintext application data remains protected, but the exact visibility of Service Identity and related metadata depends on the transport profile and any additional confidentiality mechanisms in use.¶

22. Operational Considerations

• Middleboxes SHOULD NOT assume fixed IP/port semantics for TLS-DPA channels.¶

• Monitoring SHOULD use exporter-based identity hooks rather than IP/port heuristics [NIST-SP800-207].¶

• Session resumption MUST accommodate overlay rebinds (e.g., QUIC Connection IDs, UZP SessionIDs).¶

• PQ keys and related metadata SHOULD be logged where required for compliance, in line with local policy.¶

23. Security Considerations

TLS-DPA implementations MUST:¶

1. ensure identity and transport bindings are transcript-authentic;¶

2. authenticate PQ hybrid negotiation and detect downgrades;¶

3. suppress downgrade unless explicitly permitted by policy;¶

4. minimise metadata exposure, especially in early flights;¶

5. prevent unauthorised reattachment across transports or overlays.¶

6. apply revocation policy without assuming a single global revocation authority.¶

The threat model for TLS-DPA is discussed in Section Section 21.¶

24. IANA Considerations

This document does not request any IANA actions.¶

The example code points used for extension_type values and alert descriptions in this document are intended for experimentation (for example in private-use or locally coordinated deployments). Any future request for code point allocation is out of scope for this draft.¶

Acknowledgements

The author thanks colleagues and early reviewers for discussions on identity-first security, transport binding, and post-quantum transition models. Any errors or omissions remain the author's responsibility.¶

Author's Address