IETF | Post-Quantum Authentication: Lessons from Prague

The IETF works on a broad range of networking technologies that provide the foundation for the Internet's growth and evolution.
While most IETF work takes place online, meetings and other events such as Hackathons provide in-person opportunities to advance work within the IETF.
The IETF is the premier Internet standards organization. It follows open and well-documented processes for setting these standards. Once published, those standards are made freely available.
The global IETF community works together in many different ways to produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
By supporting the IETF today, you are ensuring a free and open Internet exists tomorrow.
Email is the oldest widely used application on the Internet, but it continues to evolve. At IETF 127 four working groups will meet to improve the security and usability of mail, and two Birds-of-a-Feather sessions propose improvements in mail operations and the way users sign up for mail subscriptions.
The IETF Administration LLC has prepared its draft budget for 2027 and now seeks community feedback.
These IETF 127 meeting sessions are likely to include discussions and proposals that are accessible to a broad range of Internet technologists whether they are new to the IETF or long-time participants.
Several new features implemented on RFC-Editor.org aim to make the site more useful and engaging for RFC consumers.
A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) was completed on 11 September 2026.
Email is the oldest widely used application on the Internet, but it continues to evolve. At IETF 127 four working groups will meet to improve the security and usability of mail, and two Birds-of-a-Feather sessions propose improvements in mail operations and the way users sign up for mail subscriptions.
The IETF Administration LLC has prepared its draft budget for 2027 and now seeks community feedback.
These IETF 127 meeting sessions are likely to include discussions and proposals that are accessible to a broad range of Internet technologists whether they are new to the IETF or long-time participants.
Several new features implemented on RFC-Editor.org aim to make the site more useful and engaging for RFC consumers.
A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) was completed on 11 September 2026.
In October, the Internet Architecture Board (IAB) held a two-day workshop in Prague with people who are deploying post-quantum authentication. These are the first impressions from the co-chairs, ahead of the full workshop report.
Four obstacles came up again and again. 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 do more than swap 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.
In August we asked for evidence about what delays the deployment of post-quantum authentication in production systems. The Internet Architecture Board (IAB) workshop that followed met in Prague on 11 and 12 October. Day 1, at the Czech Technical University, brought together about forty people under the Chatham House Rule. Day 2, at Cisco, was on the record, and the twenty-two position papers and the slides are public. In this blog post, we describe what we heard from participants about these four obstacles and about AI coding agents, and what happens next.
One thing was clear: people are comfortable with post-quantum signatures from a security perspective. Nobody reported a security failure in ML-DSA or SLH-DSA. "I implemented PQC and my biggest problem was escaped ampersands," one participant said.
Ericsson's paper calls ML-DSA and SLH-DSA the only mature options for systems that must migrate by 2030 or 2031. Two hardware vendors have shipped firmware signing that combines a classical signature with LMS (RFC 8554). But in many systems, the new signatures cannot simply replace the old ones, often because they are too large for the limits those systems were built with, such as packet budgets, URL lengths, and device memory.
Post-quantum keys and signatures are a different size class from the ones they replace. An ML-DSA-65 signature is 3,309 bytes, whereas an Ed25519 signature is 64 bytes. Participants reported where the difference causes trouble: in handshakes, in signed requests and tokens, on constrained devices, and in archives. In signature validation, one participant said the main factor is the size of the key, not the math. If we were sizing a deployment, we would measure what our systems send, handshakes and requests alike, against every limit on the path. The transport layer may need to change before the credential formats.
In a handshake, larger certificates and signatures mean more packets. Going past the initial congestion window costs a round trip, and the more data a flight carries, the more likely it is to lose a packet. The network is out to get you, one participant said: even if the client and server are fine, that does not mean the middleboxes are.
In a simulation in Cisco's SD-WAN slides, 16.3% of ML-DSA-87 handshakes at 3% packet loss took more than five seconds over Datagram Transport Layer Security (DTLS) 1.2, and 0.2% over DTLS 1.3. The presenters attributed the difference to DTLS 1.2 retransmitting a whole flight of handshake messages when one datagram disappears, and proposed moving to DTLS 1.3 before changing cre