The communications industry is entering the next phase of post-quantum cryptography planning. Much of the early focus has rightly been on identifying where public-key cryptography is used and preparing migration paths to NIST-standardized post-quantum algorithms. But as the work moves from inventory to implementation, a practical question emerges: can today’s communications protocols accommodate the size and performance characteristics of post-quantum digital signatures without changing the way they operate?
Where Signature Size Matters
This question is particularly relevant for trust mechanisms such as DNSSEC, RPKI, and STIR/SHAKEN. DNSSEC supports trust in domain-name resolution. RPKI supports trust in routing authorization. STIR/SHAKEN supports authentication of caller identity information in voice networks. These are different systems, but they share a common dependency: signed objects must be generated, transported, validated, and processed at scale.
The challenge is that the current NIST-standardized ML-DSA algorithm, specified in FIPS 204, has signature sizes that are materially larger than the classical signatures many communications protocols were designed around. FIPS 204 defines three ML-DSA parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, with signature sizes of 2,420 bytes, 3,309 bytes, and 4,627 bytes respectively. These sizes may be manageable in some applications, but they can create pressure where signed objects must fit within constrained packet, header, repository, or processing assumptions.
Protocol-by-Protocol Pressure
For DNSSEC, this creates direct transport pressure. DNS commonly relies on UDP, and practical payload limits mean that larger DNSSEC responses can trigger fragmentation, truncation, or fallback to TCP. Recent IETF work on post-quantum DNSSEC has highlighted that larger PQC signatures may affect DNS response sizes and operational behavior.
A similar concern may arise in STIR/SHAKEN. STIR uses PASSporT tokens carried in SIP Identity headers. SIP already has size-related transport considerations, and larger signature material could increase header size and create new deployment, interoperability, and performance questions across SIP infrastructure, session border controllers, verification services, and interconnection points.
RPKI is different. It is not constrained by a single UDP packet in the same way, but larger post-quantum signatures and certificates can still increase repository size, synchronization overhead, validation time, and relying-party processing requirements. In other words, the issue is not always the same packet boundary. Sometimes it is the cumulative operational cost of moving larger signed objects through an architecture designed around smaller signatures.
This suggests a broader industry question: should the communications sector be examining compact post-quantum signature candidates now, so that future standards and migration guidance are informed by real protocol and deployment constraints?
The NIST Candidates
NIST is currently examining several alternative PQC signature algorithms as part of its additional digital signature evaluation process. In May 2026, NIST advanced the nine candidates listed in the table below to the third round of evaluation, with updated specifications (“tweaks”) due in August 2026. These candidates may offer different size and performance characteristics from the currently standardized ML-DSA algorithm. As shown in the table below, these candidates vary significantly across signature size, public-key size, signing speed, verification speed, implementation maturity, and underlying security assumptions. This makes some of them potentially relevant for communications protocols where a more compact quantum-safe signature may be required to preserve existing functional and architectural assumptions.
| Algorithm | Representative signature size | Relevance to constrained communications protocols |
| FAEST | ~4.5 KB–20.7 KB | Conservative design, but likely too large for inline DNS/SIP use. |
| HAWK | ~555 B / 1,221 B | Compact lattice candidate; relevant for comparison with Falcon/FN-DSA. |
| MAYO | ~186 B–964 B | Short signatures; public-key size and maturity need assessment. |
| MQOM | ~2.8 KB–17.4 KB | Small public keys, but signatures may be too large for this issue. |
| QR-UOV | ~200 B–392 B | Very short signatures; large public keys may affect certificates. |
| SDitH | ~3.7 KB–14.1 KB | Likely too large for packet/header-constrained deployments. |
| SNOVA | ~124 B–376 B | Very compact signatures; promising but still under evaluation. |
| SQIsign | ~148 B–292 B | Extremely compact; performance and maturity require assessment. |
| UOV | ~96 B–260 B | Very short signatures; very large public keys are the trade-off. |
These figures should not be treated as final deployment recommendations. Parameter sets can change, and algorithm selection must consider much more than signature length. A very small signature may come with a much larger public key. A compact scheme may have slower signing or verification. A promising candidate may require more implementation experience or additional cryptanalysis before it is suitable for critical communications infrastructure.
Building the Evidence Base
This is why further analysis is needed. The communications sector should build an evidence base to determine whether compact post-quantum signatures could support current protocol architectures more effectively than larger alternatives, and whether additional standards guidance or protocol-specific mitigations may be required. This is directly aligned with the work of ATIS’ Quantum-Safe Communications and Information Initiative (QSCII), which is focused on helping the industry prepare for practical quantum-safe migration across communications networks.
Within that context, the issue is not simply whether an algorithm is quantum-safe, but whether it can be implemented in the operational environments where communications trust is established today.
For DNSSEC, this may include understanding the impact of larger signed responses on transport behavior and resolver performance. For STIR/SHAKEN, it may include assessing how larger signatures affect SIP Identity headers, PASSporT encoding, intermediary handling, and call authentication workflows. For RPKI, it may include evaluating the implications for repository size, synchronization, relying-party validation, and operational migration.
ATIS QSCII provides a useful forum to examine these questions across protocol areas rather than treating them as isolated implementation concerns. By bringing together operators, vendors, and standards participants, the initiative can help identify where compact quantum-safe signature approaches may be needed, where current architectures can be preserved, and where further coordination with standards bodies may be appropriate.
The objective is not to select a preferred algorithm prematurely, but to build the evidence base needed to support informed standardization, identify practical deployment constraints, and determine whether compact quantum-safe signature approaches are necessary to preserve existing communications architectures where possible.
The current standardized ML-DSA signature sizes may affect existing communications protocol implementations both functionally and architecturally. By examining these NIST candidate signature algorithms today, the communications industry can begin to quantify their suitability across key trust architectures, inform future standardization, and accelerate a more practical path to PQC migration.
More information on ATIS’ Quantum-Safe Communications and Information Initiative is available at: https://atis.org/initiatives/quantum/
