DTLS 1.3 ML-KEM: Is Post-Quantum DTLS Ready for OT?

DTLS 1.3 ML-KEM means running a hybrid post-quantum key exchange, usually X25519MLKEM768, inside the Datagram Transport Layer Security 1.3 handshake defined in RFC 9147. The goal is to protect UDP traffic such as CoAP telemetry against “harvest now, decrypt later” collection. It works in principle, but kilobyte-sized key shares change how handshakes behave on lossy industrial links.

This article is for OT and critical infrastructure teams that send UDP telemetry from field devices, substations or plants to their own data centre or cloud. It covers what the standards actually say today, where the engineering problems are, and how to choose between protecting each session with DTLS and carrying traffic inside a quantum-safe tunnel.

Does DTLS 1.3 support hybrid ML-KEM key exchange?

Yes, in principle. DTLS 1.3 reuses the TLS 1.3 key_share mechanism, so the hybrid ML-KEM groups defined for TLS 1.3 can be negotiated over DTLS 1.3. Whether that works in practice depends on whether your DTLS library and device firmware implement those groups.

What the standards define

RFC 9147 was published in April 2022 and obsoletes RFC 6347 (DTLS 1.2). It is based on TLS 1.3 and gives equivalent security guarantees, except for order protection and non-replayability. Because key exchange is negotiated through the same supported_groups and key_share extensions as in TLS 1.3, any new group registered for TLS 1.3 key exchange can also be offered in a DTLS 1.3 ClientHello.

The IETF TLS Working Group’s draft-ietf-tls-ecdhe-mlkem defines three hybrid groups: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. Each one combines ML-KEM, which NIST standardised in FIPS 203 in August 2024, with an elliptic curve Diffie-Hellman exchange. If either component remains secure, the session key remains secure. That is the reason for the hybrid design during the transition.

Where the gaps are

Three practical gaps matter for OT:

• Library support. A hybrid group is only usable if both ends implement it for DTLS, not just for TLS. Many embedded stacks added DTLS 1.3 later than TLS 1.3, and their post-quantum support may lag further behind.
• Installed base. Field devices commissioned in the last decade usually speak DTLS 1.2, which cannot negotiate these groups.
• Authentication. Hybrid ML-KEM protects the confidentiality of session keys. Certificates still rely on classical signatures until post-quantum signatures are deployed in your PKI.

The deadline pressure is real. NIST IR 8547 sets the timeline for quantum-vulnerable algorithms such as RSA, ECDSA and (EC)DH:

Quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed after 2035 (NIST IR 8547, 2026).

NIST’s Dustin Moody, who heads the PQC standardization project, put it plainly: “We encourage organizations to begin their transition to these standards immediately to ensure their data remains secure in the quantum era.”

How do large ML-KEM key shares affect DTLS handshakes over UDP?

They push the ClientHello beyond a single safe datagram on many networks. DTLS then has to split the handshake across several records, and every extra datagram is another chance for the handshake to stall.

The size difference is large:

Add the DTLS record header, the handshake header, cipher suites, the server name and other extensions, and a hybrid ClientHello easily exceeds the IPv6 minimum MTU of 1280 bytes. It also exceeds what many cellular, VPN-encapsulated or legacy radio links pass without trouble. On 6LoWPAN or LoRa-class links the gap is much larger still.

RFC 9147 avoids relying on IP fragmentation. DTLS can split a handshake message across several records, each sent in its own datagram, and the receiver buffers the fragments until it has the whole message. This is better than IP fragmentation, which middleboxes and firewalls often drop. But it means a post-quantum handshake is now a multi-datagram exchange in both directions.

What happens when a DTLS handshake with post-quantum keys is fragmented and packets are lost?

The handshake waits for the missing fragment, its retransmission timer fires, and the missing data is sent again, with back-off between attempts. On lossy links this shows up as handshakes that take seconds instead of milliseconds, or that time out completely.

The handshake needs reliable delivery even though the record layer tolerates loss. To get that reliability, DTLS uses sequence numbers, a retransmission timer with back-off, and fragmentation. Measurements on constrained industrial radio show what this costs:

On an unreliable 6TiSCH link, DTLS handshake duration suffered a penalty of roughly 45%, compared with about 15% for TLS (Sensors / PMC, 2021).

That study was done with classical key sizes. A hybrid ML-KEM handshake has more fragments per flight, so each lost datagram blocks a bigger message. DTLS 1.3 helps here: it adds an explicit ACK message that acknowledges individual records. Under DTLS 1.2, retransmission worked at the level of a whole flight. With ACKs, a sender can resend only the fragments that went missing, not the entire ClientHello.

In practice, OT engineers should check four things:

• PMTU settings. Set a conservative path MTU in the DTLS stack, so fragments fit through every tunnel and radio segment on the path.
• Retransmission timers. Tune the initial timer to the real round-trip time of the link. Satellite and cellular backhaul need longer timers than a plant LAN.
• Handshake frequency. Use DTLS 1.3 Connection IDs and session resumption, so devices that change address or sleep do not run a full hybrid handshake every time.
• Firewall rules. Make sure firewalls and NAT devices on the path do not rate-limit or drop bursts of UDP datagrams to the DTLS port during the handshake.

Is CoAP over DTLS quantum safe for IIoT telemetry to your own data centre?

Not by default. RFC 7252 defines the CoAP-over-DTLS binding (coaps) around DTLS 1.2 cipher suites. Whether your telemetry is exposed to future quantum decryption depends on which security mode the devices use.

RFC 7252 describes three DTLS security modes: PreSharedKey, RawPublicKey and Certificate. Each behaves differently against a future quantum adversary:

For telemetry that stays valuable for years, such as grid topology, process recipes or load profiles, the realistic question is not “is CoAPS secure today?”. The question is whether you can upgrade every sensor, gateway and backend to DTLS 1.3 with a hybrid group before the data you send now loses its value. As the NIST CSRC puts it, “Cybersecurity products, services, and protocols will need updates, and organizations must identify where vulnerable algorithms are used and plan to replace or update them.”

Should UDP telemetry from edge devices use DTLS or be carried inside a quantum-safe IPsec tunnel?

Use DTLS where you need end-to-end protection between a device and a specific application, and where the device can run a modern stack. Use a quantum-safe network-layer tunnel where devices are constrained, legacy or numerous, and the main risk is the path between the site and the data centre.

The two approaches protect different segments. DTLS protects one application session from end to end. A site-to-site tunnel protects everything that leaves the site, whatever the protocol, but traffic inside the plant network is unprotected until it reaches the tunnel endpoint.

In IEC 62443-3-3 terms, the tunnel is a way to protect a conduit between zones. It supports the system requirements for communication integrity and confidentiality on that conduit, while devices inside each zone still need their own controls. Many operators combine the two: DTLS where modern devices and applications support it, and a tunnel for the rest of the site’s traffic.

One example of the tunnel approach is Quantum Network’s QPN gateway. It sits at each end of a connection, encrypts at Layer 3 and uses a hybrid key agreement in which a classical part and ML-KEM (FIPS 203) are combined into one session key, with both handshakes renewed every two minutes. No software is installed on the equipment behind it. For edge-to-cloud telemetry, a virtual QPN gateway can run on a supported Linux platform in the organisation’s own data centre or cloud, so UDP flows from a site arrive inside the tunnel without any changes to sensors or PLCs.

A practical decision sequence

1. Inventory UDP flows per site: protocol, DTLS version, security mode (PSK, RPK, certificate) and how long the data stays sensitive.
2. Measure the links: path MTU, loss rate and round-trip time on each backhaul type. These numbers decide whether multi-datagram hybrid handshakes are realistic.
3. Classify devices into those that can be upgraded to DTLS 1.3 with hybrid groups within your NIST IR 8547 timeline, and those that cannot.
4. Tunnel the remainder between site and data centre, and keep zone segmentation inside the site.
5. Re-evaluate when the IETF TLS Working Group’s hybrid draft becomes an RFC and your DTLS library vendors ship stable support.