In October, the Internet Architecture Board (IAB) held a two-day workshop in Prague with people who are deploying post-quantum authentication. Four obstacles came up again and again. “I implemented PQC and my biggest problem was escaped ampersands,” one participant shared, highlighting practical implementation issues beyond purely cryptographic concerns. The IAB plans to publish a full report detailing these obstacles and potential solutions.

Post-Quantum Key & Signature Size Impacts on Systems

The substantial increase in signature size presented by post-quantum cryptography (PQC) is creating immediate deployment challenges, with an ML-DSA-65 signature reaching 3,309 bytes compared to the 64 bytes of an Ed25519 signature. These limitations extend beyond initial handshakes to affect signed requests, tokens and even long-term archival of data. Validating signatures, workshop attendees noted, is increasingly constrained by key size rather than the complexity of the underlying mathematics.

Thorough assessment of data transmission across systems is essential; measuring the size of handshakes and requests against every limit along the communication path is essential before deployment. The transport layer itself may require modification before credential formats can be updated, as larger certificates and signatures translate directly into more packets transmitted. Sean Turner cautioned against implementing PQC with DTLS 1. 2, highlighting the potential for increased packet loss and round trip times due to the increased data volume.

Identity systems, reliant on signatures embedded within tokens and requests, are particularly vulnerable to these size constraints. The UK Government Digital Service conducted tests demonstrating a significant increase in data transmission during identity verification processes. A typical journey grew from 6. 7 KB to 44. 5 KB when using ML-DSA-65 signatures and ML-KEM-768 key exchange. Similarly, signed OAuth requests embedded in URLs face limitations imposed by various components, with Amazon’s CloudFront imposing an 8 KiB limit and load balancers restricting request lines to 16 KiB.

These constraints force difficult trade-offs between security and functionality. Beyond immediate size limitations, the IAB workshop revealed concerns about the long-term security implications of transitioning to PQC. Participants discussed the potential for “forge-later attacks,” where adversaries use quantum computing to compromise authentication systems reliant on long-term trust.

Netflix’s paper detailed this threat, explaining that an attacker capable of breaking the classical signature validating a new root certificate could forge their own, unlocking access to an entire fleet of systems. David Benjamin, in a paper for Google, articulated the overarching goal: to ensure an active attacker with a quantum computer cannot intercept communications between updated clients and services. The IAB noted in August that each solution shifts costs from one constraint to another, and the Prague discussions reinforced this point.

Participants suggested that simplifying authentication processes, such as avoiding signatures when third-party verification is unnecessary, could offer more immediate benefits than solely focusing on new cryptographic algorithms. Determining what genuinely requires signing is therefore a critical first step.

Ericsson’s paper identified ML-DSA and SLH-DSA as the only mature options for systems requiring migration by 2030 or 2031, suggesting a narrowing of viable solutions. However, the unfortunate reality of the transition to ECDSA was also raised, implying that past migrations were not without their own difficulties.

“The thing that you’re rooting is the thing that’s about to die,” one attendee observed, emphasizing the need for careful planning and consideration of long-term implications when selecting and deploying PQC solutions. Another participant expressed a lack of trust in the cryptography itself, stating simply, “I don’t trust the cryptography.”

Please don’t do DTLS 1.2 and PQ [post-quantum cryptography].
Sean Turner

Verifiers Lead Post-Quantum Email Migration Timelines

This dynamic shifts the traditional understanding of migration timelines, placing the onus on those who validate digital identities rather than those who issue them. The workshop revealed a fundamental asymmetry in the transition process, with verifiers facing the longest deployment timeline but must move first.

A complete migration isn’t achieved with merely some verifiers accepting post-quantum certificates; it demands the cessation of trust in classical roots, a point emphasized by Benjamin, who described deleting classical trust on the client as “the durable end state.” This means a vendor like Cisco, whose SD-WAN routers may retain factory-installed classical certificates until approximately 2035, effectively extends the window of vulnerability. The company acknowledged that as long as these certificates remain valid, a successful forgery of a classical certificate could compromise network control.

The logistical challenges extend beyond hardware replacement. npm, the package registry, anticipates a minimum 12-month delay before offering post-quantum signature verification, awaiting widespread adoption of a compatible command-line interface. This cautious approach mirrors the incomplete transition to ECDSA, where Let’s Encrypt continues issuing RSA certificates to maintain compatibility with older clients. The IAB co-chairs noted that the parts of a system taking the longest to change are also the parts that must change first, a paradox that complicates planning and execution. The implications of this protracted timeline are significant.

The IAB’s earlier assessment that the threat to authentication may be further off than the threat to key establishment is now refined by the Prague discussions. This understanding is important, as it emphasises that authentication work cannot be deferred until key-establishment migration is complete. The workshop report, expected shortly, will document these findings without offering prescriptive guidance, instead presenting a record of the discussions.

However, one clear takeaway emerged: the migration is a complex orchestration of updates across a diverse ecosystem. As one attendee succinctly put it, the challenge “is not a substitution problem,” but a systemic one demanding coordinated action from verifiers, certificate authorities and software vendors alike.

turn a zero-day into a 20-day.
Benjamin

DTLS 1.2 Packet Loss Hinders Post-Quantum Handshakes

Network limitations are already impeding the rollout of post-quantum cryptography, with older protocols proving particularly vulnerable. Simulations presented by Cisco revealed that 16. 3% of ML-DSA-87 handshakes using Datagram Transport Layer Security (DTLS) 1. 2 experienced delays exceeding five seconds with just 3% packet loss, a stark contrast to the 0. 2% experiencing similar delays with DTLS 1. 3.

The discrepancy arises from DTLS 1. 2’s practice of retransmitting entire flights of handshake messages upon losing a single datagram, a significant inefficiency that exacerbates network congestion. 2, stating, “Please don’t do DTLS 1.2 and PQ [post-quantum cryptography].” The increased size of post-quantum signatures presents challenges beyond handshake delays, impacting systems with inherent size constraints.

Participants in the Prague workshop reported issues with these larger signatures in handshakes, signed requests, constrained devices and long-term archives. The transition to post-quantum cryptography is further complicated by the need to maintain backwards compatibility and the limitations of existing infrastructure.

One participant noted that simply issuing post-quantum certificates from an existing ECDSA hierarchy would “break more than 1% of our customers,” acknowledging “the unfortunate reality of how poorly the transition to ECDSA has gone.” The core issue lies in the fact that even with post-quantum certificates in place, a system remains vulnerable as long as it continues to accept classically signed certificates.

The paper emphasizes that a client is only truly protected when it ceases to trust classical roots, a step that cannot be taken until the vast majority of services have migrated to post-quantum signatures. This creates a chicken-and-egg scenario where widespread adoption is hindered by the need for universal support, and attackers can exploit the continued acceptance of older, forgeable signatures, using what the IAB describes as “where attackers use quantum computing to forge authentication in systems that rely on long-term trust.”

PQ certs just waste bytes.
Google

Regulatory & Technical Fragmentation Risks Authentication

The IETF workshop in Prague revealed four obstacles. First, the new keys and signatures break old size limits. Second, verifiers and their roots have the longest deployment timeline but must move first, and migration isn’t complete until verifiers stop accepting classical roots. Third, several proposed approaches offer more than a simple swap of a classical signature algorithm for a post-quantum one, and each of them comes with costs.

Fourth, diverging regulatory requirements and technical constraints are driving different approaches to post-quantum authentication, creating a risk of fragmentation. A signer cannot transition to post-quantum cryptography until the verifying entities, browsers, card readers, or device boot code, are capable of validating the new signatures. The IAB workshop that followed met in Prague on 11 and 12 October. The report will focus on recording the observed obstacles and takeaways, allowing stakeholders to draw their own conclusions.