Post-quantum cryptography for voice interconnection — encryption, authentication, SIP over TLS and STIR — library

A voice network uses public-key cryptography in up to three places. Providers that interconnect over IP can secure the SIP signaling between their session border controllers with TLS, ideally mutual TLS so each side authenticates the other. Most PSTN interconnection does neither today; mutual TLS is found mainly in UCaaS and newer SIP deployments. STI certificates bind a provider’s signing key to its numbering authority. And every signed call carries a PASSporT signed with ES256. STIR and SHAKEN use ECDSA throughout, which a large quantum computer would break; which algorithms interconnection certificates use is set by each provider’s TLS configuration and, for agreement-less interconnection (ALIII), by an IP-NNI certificate profile that is not yet public. This page covers what replaces each one, using the NIST and IETF documents that define the replacements.

Two problems, two deadlines

Post-quantum migration is two separate problems.

Encryption protects the content of a session. Traffic recorded today can be decrypted once a quantum computer exists, so encryption has to move before that point, and anything sent before it moves is already exposed. Only the key agreement changes. Symmetric ciphers such as AES-128-GCM stay as they are; the threat is to the elliptic-curve key exchange that sets up the session key.

Authentication proves who signed something or who is on the other end of a connection. A signature verified today cannot be forged retroactively, so there is no harvest-now risk. Authentication has to move before a quantum computer can forge signatures in real time, and it only protects anyone once verifiers stop accepting the old algorithm. A verifier that accepts both ML-DSA and ES256 can still be fooled by a forged ES256 signature.

The two are at different stages. Hybrid key agreement for TLS 1.3 is published as RFC 10024 (August 2026), and Cloudflare reports that more than 65% of human traffic to its network is already post-quantum encrypted (Cloudflare). The same post says post-quantum authentication will take years, because it runs through certificate authorities, verifiers, hardware and third parties, and because it requires turning the classical algorithms off. The IAB held a workshop in October 2026 on why post-quantum authentication has not deployed; its position papers are on the datatracker.

NIST IR 8547 sets the dates. RSA and ECDSA signatures at 112 bits of security strength, and EdDSA at 128, are deprecated after 2030 and disallowed under NIST standards after 2035. ES256 is ECDSA at 128 bits, so every STI certificate and PASSporT falls in that table. The dates bind federal systems; for carriers they are guidance, not a mandate. IR 8547 accepts dual signatures on certificates and on user data such as e-mail, as long as one component algorithm is NIST-approved.

The algorithms

Algorithm	Standard	Use	Public key	Signature or ciphertext
ECDSA P-256 (ES256)	in SHAKEN today	signatures	64 bytes	64 bytes
ML-KEM-768	FIPS 203	key agreement	1,184 bytes	1,088 bytes
ML-DSA-44	FIPS 204	signatures	1,312 bytes	2,420 bytes
ML-DSA-65	FIPS 204	signatures	1,952 bytes	3,309 bytes
ML-DSA-87	FIPS 204	signatures	2,592 bytes	4,627 bytes

SLH-DSA (FIPS 205) is the hash-based alternative, with small keys and signatures several times larger again. The IETF has defined how each is carried: RFC 10024 for hybrid key agreement in TLS 1.3, RFC 9881 for ML-DSA keys and signatures in X.509 certificates, and RFC 9964 for ML-DSA in JOSE and COSE, which registers ML-DSA-44, ML-DSA-65 and ML-DSA-87 as JWS algorithms and the AKP key type. Composite signatures, which pair ML-DSA with a classical algorithm in a single key and signature, are in the RFC Editor queue as draft-ietf-lamps-pq-composite-sigs.

Encryption has to come first

Post-quantum key agreement upgrades encryption that is already there. Most IP voice interconnection today has none. In my experience SIP signaling between providers runs over UDP or TCP on dedicated or managed links, and the RTP media runs unencrypted beside it; private links are where that has been accepted. ATIS’s report on VoIP interconnection over the public internet (ATIS-1000100) recommends securing both signaling and media once interconnection moves there.

Signaling and media have to be encrypted together. With SDES (RFC 4568), common in SIP trunking, the SRTP media keys travel in the SDP inside the SIP message, so encrypting the media while leaving the signaling in the clear hands the keys to anyone who can read the signaling. SDES also ties the media’s post-quantum protection to the signaling’s: a recording of TLS-protected signaling that a quantum computer can decrypt yields the SDES keys, and the recorded media can then be decrypted with them. The keys are also visible to every proxy and border controller that terminates TLS along the path. With DTLS-SRTP (RFC 5763, RFC 5764) the media endpoints run their own handshake, which needs a hybrid group of its own. SRTP’s AES cipher does not change in either case.

Private networks are not a reason to skip this. NIST’s Zero Trust Architecture (SP 800-207) makes it a tenet that all communication is secured regardless of network location, and a dedicated link between two providers is no exception. My view is that SIP over TLS with SRTP belongs on every interconnection link, public or private, and post-quantum key agreement belongs on each of them once that is in place.

Encryption on interconnection links

RFC 10024 defines three hybrid groups for TLS 1.3. X25519MLKEM768 combines X25519 with ML-KEM-768 and adds about 1.2 KB to each side of the handshake; SecP256r1MLKEM768 and SecP384r1MLKEM1024 use NIST curves. A session is secure if either component holds.

X25519MLKEM768 is the group browsers and Cloudflare negotiate on the public internet, which is why it reads as the only post-quantum option in use. It is a key-agreement group, not a signature algorithm, and it is one of three. X25519 is not a NIST-approved key-establishment scheme; the hybrid is acceptable under NIST rules because its ML-KEM component is. SecP256r1MLKEM768 exists for deployments that need both components to be NIST-approved, and SecP384r1MLKEM1024 matches the ML-KEM-1024 that the NSA’s CNSA 2.0 suite requires for national security systems. No ATIS or SIP Forum document names a group for interconnection links. For signatures, ML-DSA and SLH-DSA are approved and published, but no publicly trusted certificate authority issues them and browsers do not accept them.

SIP signaling between providers carries the calling and called numbers, the PASSporT, and any rich call data for every call. Where SIP over TLS crosses the public internet, as the agreement-less model in the IP-NNI task force proposes, it is the traffic the harvest-now threat applies to. Moving it to a hybrid group is a TLS library and configuration change on the session border controller. It does not depend on any STIR or ATIS document.

Two practical points follow from how the web did it. The session border controller is where post-quantum TLS terminates, so the link between providers is protected while legs behind it are not until they are upgraded separately. And an operator cannot plan without measurement: a border controller that logs the negotiated key-exchange group per peer tells an operator which interconnections are already post-quantum.

Authentication: three places, three constraints

Interconnection TLS certificates. These are the certificates providers present to each other on SIP over TLS, where they use it, and both sides present one only under mutual TLS. For agreement-less IP interconnection (ALIII), the ATIS/SIP Forum IP-NNI task force’s trust architecture and certificate management document covers their issuance, validation, renewal, rekey and revocation. It is scheduled about a month after the first two ALIII documents, which are due in December 2026, per AT&T’s declaration in WC Docket 25-304. The drafts are not public. A TLS connection between two border controllers is long-lived, so the cost of a larger certificate is paid once per connection, not once per call. RFC 9881 certificates work in a closed PKI like this one. Chrome’s quantum-resistant program accepts only Merkle Tree Certificates for the public web, but Chrome expects to support post-quantum X.509 certificates in private PKIs (Chrome).

STI certificates. A verifier does not receive the certificate chain in the call. It follows the x5u URL in the Identity header, fetches the certificate, and can cache it. An ML-DSA certificate chain is several kilobytes larger than an ECDSA one, and that cost falls on the fetch, not on the SIP message.

The PASSporT signature. This is the cost that recurs on every call. STIR requires implementations to support ES256, and SHAKEN signs with ES256 alone. An ES256 signature is 86 base64url characters in the Identity header; an ML-DSA-44 signature is about 3,230. RFC 3261 requires a request larger than 1,300 bytes, when the path MTU is unknown, to go over a congestion-controlled transport such as TCP, so a post-quantum PASSporT ends the use of UDP for signed calls. RFC 9964 already registers ML-DSA for JWS, so a PASSporT signed with ML-DSA-44 can be built today with ordinary JOSE libraries. What does not exist is a STIR or SHAKEN document that permits an algorithm other than ES256, or that sets a size budget for the Identity header.

Ericsson’s position paper to the IAB workshop reports that ML-DSA and SLH-DSA meet telecom performance requirements in its benchmarks (S45). Nokia’s paper makes the point that governs the cutover: post-quantum authentication delivers its benefit only once traditional authentication can be rejected, and in operator networks that waits on the slowest of module support, product integration, certification and credential issuance (S44). For STIR that means a date after which a verification service refuses an ES256 PASSporT, which is a governance decision for the STI-GA, not a protocol one.

What transfers from the web PKI

Merkle Tree Certificates, specified in draft-ietf-plants-merkle-tree-certs, are the IETF’s answer to post-quantum signature size on the web. The draft’s authors are from Google, Apple, Cloudflare and Geomys, and Let’s Encrypt reported its implementation of an MTC certificate authority to the IAB workshop (S32). A certificate authority appends every certificate it issues to a log and periodically signs the log’s tree head; independent cosigners check each tree head against the last. A certificate then carries an inclusion proof up to a tree head the relying party already trusts, in place of a CA signature. A certificate cannot be issued without being logged. Relying parties have to receive trusted tree heads ahead of time over an update channel the draft leaves unspecified, and a party without a current one gets a standalone certificate carrying the cosignatures instead. Chrome’s quantum-resistant root store will accept only these, with launch planned for the third quarter of 2027.

For STIR the size saving matters less, because the certificate chain is fetched out of band. The issuance model matters more. STI verification services are a small, known population that can keep tree heads current, which is the condition the design depends on, and draft-ietf-stir-certificate-transparency already defines logs for STI certificates. Merkle Tree Certificates do nothing for the per-call PASSporT signature. The draft describes the authenticating party generically and maps it to TLS as the side that sends the certificate; it does not address mutual TLS explicitly, so whether it fits the client side of SIP over mutual TLS is an open question.

What is realistic to adopt

My view: voice should not write its own post-quantum profile. The web has the operational experience, the interop testing and the root-program policy, and voice has none of the three. The realistic path is to adopt what the web has deployed, in the form the web has deployed it, and to wait for the web where it has not decided.

Encrypt signaling and media on every link. SIP over TLS and SRTP, public internet or private, before any post-quantum step.
Key agreement: X25519MLKEM768. It is what the major TLS stacks ship and what browsers negotiate at scale, so it is what border controller vendors will get from their TLS library. Use SecP256r1MLKEM768 only where a customer requires both components to be NIST-approved.
Certificates for SHAKEN and SIP over TLS: ML-DSA in X.509, per RFC 9881. Both are private PKIs, and that is the form Chrome supports for private PKIs. ML-DSA-44 is the smallest parameter set, and size is the constraint that matters for a per-call signature.
No composite certificates. No root program and no CA/Browser Forum proposal backs composite certificates for TLS, so there is no web interop experience to borrow.
Transparency on the web model. Merkle Tree Certificates and Certificate Transparency are where the web is putting post-quantum authentication; draft-ietf-stir-certificate-transparency already follows that model for STI certificates.
PASSporT follows JOSE. The per-call signature has no web PKI equivalent. Its closest analog is a signed JWT, and RFC 9964 already defines ML-DSA for JOSE; what OpenID Connect and the wider JOSE ecosystem deploy is what PASSporT should take.
Timing follows the root programs. Chrome plans to launch its quantum-resistant root store in the third quarter of 2027. Voice should adopt each piece after the web has interop experience with it, not before.

The CA/Browser Forum has not settled post-quantum certificates. Ballot SC-106, which would have allowed ML-DSA in publicly trusted TLS certificates, has not gone to a vote; commenters for Chrome said the construction was not viable for browsers and suggested a separate working group for non-browser relying parties (SC-106). If that group is chartered, it is where an ML-DSA profile for private PKIs would be written, and it is the venue SHAKEN and the IP-NNI interconnection profiles should use rather than writing their own.

What is open

No STIR, SHAKEN or ATIS document addresses post-quantum algorithms for PASSporT, STI certificates or SIP interconnection over TLS.
PASSporT needs a permitted ML-DSA algorithm and a decision on hybrid or dual signatures versus pure ML-DSA.
The Identity header needs a size budget, and SIP over UDP cannot carry it.
The IP-NNI certificate profile for ALIII is not public, so it is not known whether it allows algorithm change without reissuing the PKI.
A date for verifiers to stop accepting ES256 needs an owner.