The argument for hybrid
A hybrid key exchange derives the session key from two or more independent key exchanges. In a VPN migration the pair is normally one classical exchange, such as ECDH on a well-understood curve, and one post-quantum exchange, such as ML-KEM.
The reasoning is straightforward. The classical algorithm has decades of cryptanalysis behind it and is believed to be secure against every adversary except a sufficiently large quantum computer. The post-quantum algorithm is believed to be secure against that adversary, but has a much shorter analytical history. Combining them means the session key holds as long as either algorithm holds.
That is a materially different risk position from replacing one with the other, which would mean betting every tunnel on the newer algorithm being correct. For infrastructure that is expected to run for years without revisiting, hybrid is the conservative choice, and conservatism is the right instinct when the failure mode is silent.
How IKEv2 negotiates it: RFC 9370
Before RFC 9370, IKEv2 negotiated exactly one key exchange method per SA. There was no place in the protocol to put a second one.
RFC 9370, Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2), published in May 2023, changes that. Its abstract describes the mechanism directly:
This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup.
Three parts of the design matter operationally:
It uses the IKE_INTERMEDIATE exchange. RFC 9370 builds on RFC 9242, which defines an intermediate exchange that runs between IKE_SA_INIT and IKE_AUTH. That is where the additional key exchanges happen. A gateway therefore needs RFC 9242 support before RFC 9370 support is meaningful, and this dependency is a common reason a device that appears to have the right release still cannot negotiate.
It adds up to seven additional key exchanges. The specification designates additional transform types, referred to as ADDKE, so more than one extra exchange can be negotiated alongside the original. Most enterprise deployments use exactly one.
It renames things. RFC 9370 updates RFC 7296 by renaming Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)", and renaming the corresponding payload field. This is cosmetic in the protocol and occasionally confusing in practice, because vendor documentation and CLI output may use either name depending on when it was written.
For rekeying and for creating additional Child SAs, RFC 9370 introduces a further exchange, IKE_FOLLOWUP_KE, used for the same purpose.
The other mechanism: preshared key mixing
RFC 9370 is not the only route. RFC 8784, Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security, published in June 2020, takes a different approach: it mixes an out-of-band post-quantum preshared key (PPK) into the derived keys.
The RFC is explicit about why it exists. Its abstract states:
It is anticipated that IKEv2 will be extended to support quantum-secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys.
The two mechanisms are not equivalent, and the differences drive real decisions:
| RFC 9370 additional key exchanges | RFC 8784 preshared key mixing | |
|---|---|---|
| What is added | A negotiated post-quantum key exchange | An out-of-band symmetric key |
| Key distribution | None; negotiated in-protocol | Manual, out of band, per peer pair |
| Ongoing operational cost | Low once configured | Continuous: distribution and rotation |
| Scales to many peers | Yes | Poorly |
| Available on older platforms | Less often | More often |
RFC 8784 also states its own limitations clearly: the mechanism protects SK_d and the keys derived from it, while information exchanged during the initial IKE SA setup — identities, notifications, vendor IDs — remains exposed to a future quantum adversary. It also requires the PPK to carry more than 256 bits of entropy.
In practice RFC 8784 is often the only option available on an older platform, and it is a legitimate interim answer. It is not a good permanent answer for an estate with many peer relationships, because the symmetric key distribution and rotation burden grows with every peer.
What hybrid does not give you
Hybrid key establishment protects the session key. It does not change peer authentication.
A tunnel using ML-KEM alongside ECDH still authenticates its peer with whatever it authenticated with before — an RSA certificate, an ECDSA certificate, or a preshared key. Post-quantum authentication is a separate problem addressed by post-quantum signature standards and by the PKI that issues the certificates. See ML-KEM and FIPS 203 for why that gap is usually acceptable and when it is not.
Operational cost to plan for
Hybrid is not free, and an assessment should price these in:
- Larger handshake payloads. Post-quantum public keys and ciphertexts are substantially larger than elliptic curve ones. On paths with constrained MTU this interacts with IKE fragmentation behaviour, and fragmentation problems tend to present as intermittent tunnel establishment failures rather than as clean errors.
- More exchanges. The IKE_INTERMEDIATE exchange adds round trips to SA establishment. On a high-latency path this lengthens establishment and re-establishment time, which matters most during a failover.
- Both peers, always. There is no unilateral hybrid. Every tunnel is a coordination problem, and every tunnel terminating on a partner device is a coordination problem with another organisation's change process attached to it.
- Verification is not optional. Because the change is negotiated, configuring it is not the same as achieving it. See verifying a post-quantum VPN migration.