Keep the proof. Rethink the reconnect.

A connection ends. The work does not.

A laptop wakes in a hotel room. A phone leaves office Wi-Fi for a cellular network. A gateway drains connections during maintenance. To the person using a corporate application, these are interruptions to one continuous task. To the transport, they can be entirely new sessions, each asking the same expensive question: can this endpoint prove that it holds the private key for an identity we trust?

That question becomes particularly interesting with post-quantum authentication. ML-DSA offers standardized lattice-based signatures, but its smallest signature is 2,420 bytes. Multiply repeated proofs by mobile reconnects and a large fleet, then add certificate chains, key shares, and packet loss. The signature is only one component, yet it is a component worth understanding before deciding how to optimize the system.¹

The research report Making ML-DSA Practical for Client mTLS makes a useful architectural proposal: preserve the cryptographic proof and change how frequently the connection needs a fresh one. Its ML-DSA Bootstrap and Adaptive Resumption profile, abbreviated MBAR, combines a full authenticated bootstrap with tightly governed TLS resumption. MBAR is the report’s proposed deployment profile, not a new signature algorithm or an IETF standard.²

For Antara Secure Access, this is an engineering question about the complete access lifecycle: how the client proves its identity, how the gateway proves its own, and what must still be true when a session reconnects. Certificate exchange is a core part of that architecture. A shorter reconnect must preserve the organization’s authority to change its mind about access.

Three operations hiding inside one handshake

A certificate, a live proof, and a shared secret solve different problems. The certificate authority signs an identity binding when it issues a certificate. The endpoint later demonstrates possession of its own private key. Key agreement establishes material used to derive session keys. Calling all three “PQC certificate exchange” hides the places where algorithm policy needs to be explicit.

An ML-DSA subject key does not automatically imply that every issuer in its chain also uses ML-DSA. RFC 9881 specifies ML-DSA identifiers for X.509; the issuer’s signature and the subject’s public key remain separately visible choices. Client and gateway therefore need an agreed trust profile, including acceptable chains, key usages, identity mapping, and revocation behavior.³

The same separation applies to mutual TLS. Both parties authenticate, but their certificate paths may be administered by different teams. A client credential from an enterprise PKI and a gateway credential from a service PKI have to meet at a compatible policy boundary. Hybrid key agreement protects the new session’s secret; it does not repair an invalid certificate or an unauthorized identity.

Why the signature will not become a tiny blob

The report examines the ML-DSA encoding instead of assuming ordinary compression will solve the problem. Most of the bytes belong to the response vector, conventionally named z. For ML-DSA-44, that component alone occupies 2,304 bytes. Eliminating every other field would still leave far more than a typical classical signature, and would no longer leave a valid standardized ML-DSA signature.²¹

Certificate compression addresses a different object. RFC 8879 compresses the TLS Certificate message. Repeated naming and certificate metadata may offer savings, but the mechanism does not compress CertificateVerify. A shorter chain or better certificate encoding can improve the total handshake without changing the standardized signature at all.⁴

This distinction is operationally valuable. It gives each optimization a measurable target: chain bytes, proof bytes, key-share bytes, number of round trips, or repeated full authentications. A benchmark that reports only “smaller PQC handshakes” is incomplete until it says which of those changed.

Authenticate fully. Resume deliberately.

The full handshake supplies the expensive proof. The gateway then records the identity and policy context that made access legitimate. A later resumption can refer to that context using a ticket and demonstrate possession of the associated resumption secret. The ticket must not become an ungoverned alternative credential whose lifetime quietly exceeds the certificate or authorization behind it.²

The proposed profile uses PSK-DHE resumption with fresh hybrid key agreement. Ordinary TLS resumption does not send a new client CertificateVerify: authentication continuity comes from the resumption secret derived from the earlier authenticated session. That is a meaningful change in the proof being presented, even when the original bootstrap used ML-DSA. Sensitive administrative actions should not be sent as replayable 0-RTT application data.⁵²

The hard part is remembering what still holds

A useful ticket record binds tenant, authenticated identity, credential fingerprint, full-authentication time, expiry, server audience, cryptographic profile, and the policy versions relevant to access. Revocation and posture freshness need their own treatment. A ticket that remains decryptable is not necessarily a ticket that remains acceptable.

An opaque, stateful ticket can keep the client’s reference compact while making invalidation explicit. It also creates a distributed-systems obligation: a gateway must learn about state changes in time to enforce them. Across regions, the important measurement is not just ticket lookup latency but the longest interval in which a revoked session could still be accepted.²

This is where the wider Antara access model matters. Device posture and Bluetooth companion presence can change session eligibility; the agentic auditor can connect the resulting events to the identity, resource, and policy version. Those signals do not modify an ML-DSA signature. They determine whether the system should continue relying on the earlier authentication at all.

Spend the proof once, account for every reconnect

Consider one full ML-DSA-44 client proof followed by eligible resumptions. Let N be the total number of connections and assume a 32-byte binder on each resumed connection. The average for these selected proof components is (2420 + 32 × (N − 1)) / N bytes per connection. The formula includes the first connection; N is not the number of resumptions.

At eleven total connections, this model gives about 249 bytes per connection. At sixty-two, it gives about 70.5. The original 2,420-byte signature has not shrunk. Its cost has been spread over several connections that remain eligible to inherit the original authentication context. That is amortization, and its benefit depends on how often policy permits resumption.²

These values are not complete handshake sizes or measured Antara results. Fresh hybrid key shares, ticket identities, server authentication work, framing, and application traffic are outside this graph. Frequent full reauthentication reduces the savings. Longer continuity windows increase the burden on revocation and policy enforcement. The right deployment chooses that tradeoff from its security requirements, rather than from the prettiest byte count.

Make the migration observable

An enterprise rollout starts by inventorying the TLS termination points and the clients behind them. Record which peers support the required certificate algorithms, which libraries handle the intended signature schemes, and where traffic is re-encrypted. The ML-DSA TLS signature specification remains an Internet-Draft at the time of this article; a controlled native-client deployment and a public-browser deployment do not have identical compatibility constraints.⁶

Test full authentication, eligible resumption, deliberate ticket rejection, certificate expiry, and emergency revocation. Run the same workload across realistic round-trip delay and packet loss, then report p50, p95, and p99 completion times. On mobile devices, include wake-up behavior and energy use. A fast successful reconnect is only half the story; an invalid reconnect must fail quickly and explainably.

The supplied research proposes this evaluation program. It does not supply an Antara production benchmark. Its most durable contribution is the boundary it draws: standardized cryptographic proofs remain intact, while deployment engineering reduces repetition around them. For a secure-access client, that is a stronger foundation than promising that every certificate will magically become small.²