Distinguish RFC 9370 (multiple key exchanges in IKEv2) from RFC 8784 (PPK mixing) as different mechanisms, and when each is used
Explain how OpenSSH deploys hybrid key exchange (mlkem768x25519-sha256) by default today, and how a downgrade attack documented by RFC 9370 itself is prevented
In the previous lesson you measured TLS’s hybrid key exchange. This lesson shows how the same “hybrid key exchange” idea is applied in two different protocols (IKEv2/IPsec VPNs and SSH); both have different standards and different deployment speeds from TLS.
IKEv2: two different mechanisms, not to be confused
On the IKEv2 side (the key exchange protocol of IPsec VPNs) there are two separate PQ-resistance mechanisms that do not substitute for each other. RFC 8784 (June 2020, older) is a simple idea: if the parties already share a symmetric secret over a secure channel (a Post-quantum Preshared Key, PPK, with at least 256 bits of entropy), they mix that secret into IKE’s key derivation; no PQC algorithm (such as ML-KEM) is needed, just a strong shared secret. RFC 9370 (May 2023, newer) takes a different approach: a real hybrid KEM exchange, adding algorithms such as the ML-KEM you saw in M3 next to classical ECDH, up to 7 layers. RFC 9370 does this with two new IKEv2 exchanges: IKE_INTERMEDIATE (for additional key exchanges while the IKE SA is first set up) and IKE_FOLLOWUP_KE (for rekeying or new Child SAs).
The downgrade attack RFC 9370 documents itself
RFC 9370’s Appendix C openly documents an approach considered and rejected during the design process, and why it was rejected: when sending the hybrid post-quantum offer directly in the first KE (key exchange) payload (a single unit of data carried by IKEv2 messages, such as a key or a notification) was tried, it was found that an attacker could intervene and reply with an N(INVALID_KE_PAYLOAD) notification, downgrading the parties to classical Diffie-Hellman. RFC 9370’s actual design prevents this: the initiator must state its preferred post-quantum proposals and policies in a separate notify payload (a payload type that carries a notification) instead of relying only on the KE payload; this stops an attacker from silently cancelling the whole PQC negotiation by getting a single payload rejected. It serves the same goal as TLS 1.3’s downgrade protection logic, which you saw in M6, with a different mechanism: TLS 1.3 does it by authenticating the whole negotiation retroactively after the connection is set up (with the MAC in the Finished message), while RFC 9370 does it during the negotiation with a protocol rule (the PQC preference must be in a separate, restated notification). Both reach the goal “a party’s PQC request cannot be silently ignored”, with different tools.
SSH: quietly, it has largely already happened
On the SSH side the transition moved at a different speed from TLS. OpenSSH’s own official page gives a clear timeline: DEPLOYED2022-04-08 since OpenSSH 9.0, sntrup761x25519-sha512 (the first PQ hybrid key exchange, not a standard NIST algorithm but an early hybrid option) has been supported; DEPLOYED2024-09-19 since OpenSSH 9.9, mlkem768x25519-sha256 (FIPS 203’s ML-KEM-768, which you saw in M3) has been supported; and DEPLOYED2025-04-09 since OpenSSH 10.0 the latter is the default. This parallels the browser-side DEPLOYED example from Cloudflare that you saw in M5, but in the SSH world: not a roadmap promise but a default everyone installing a current OpenSSH gets automatically today.
The way for a system administrator to verify this is simple: ssh -Q kex lists supported algorithms, and ssh -vv shows which algorithm is negotiated on a real connection. Even with a current version, a KexAlgorithms restriction in a configuration file or an older peer can silently fall back to a classical key exchange; “we run a current version” and “we really negotiate a PQC key exchange” are different claims, a “claim versus verify” discipline similar to the CAVP/CMVP distinction in M5.
Numbers to know
OpenSSH has supported sntrup761x25519-sha512 since 9.0 (April 2022) and mlkem768x25519-sha256 since 9.9 (September 2024); since 10.0 (April 2025) the latter is the default
RFC 9370 can add up to 7 layers of KEM on top of the original ECDH with the IKE_INTERMEDIATE and IKE_FOLLOWUP_KE exchanges; RFC 8784 instead mixes in a single symmetric preshared key (at least 256 bits of entropy), with no KEM at all
Lab: Check the hybrid key exchange status of your own SSH client
You will see the line "kex: algorithm: mlkem768x25519-sha256" (even if the connection fails, the key exchange negotiation shows on this line)
At the table
How to say this in a bank meeting.
To an executive
The PQC transition covers not only web traffic (TLS) but also VPNs (IKEv2/IPsec) and system administration access (SSH). On the SSH side the transition has largely already happened (it is OpenSSH's own default); on the VPN side the standard is ready but deployment depends on the vendor.
To an architect
Do not confuse RFC 9370 and RFC 8784: 9370 is a real hybrid KEM exchange (using PQC algorithms such as ML-KEM), while 8784 is simpler and only mixes in a strong preshared key, needing no PQC algorithm. They are not substitutes but fit different scenarios: 8784 is simpler for a closed network that can already distribute a PPK over a secure channel; 9370 is general purpose, for scenarios with no PPK distribution infrastructure.
Objection
“"Our SSH is already up to date. Does that mean we automatically use PQC?"”
Answer
If it is OpenSSH 10.0 or later and the other side is compatible, yes, `mlkem768x25519-sha256` is negotiated by default; but instead of assuming that, check the algorithm actually negotiated with `ssh -vv`, because even with a compatible version, a `KexAlgorithms` restriction in a configuration file or an older peer can silently fall back to a classical key exchange.
OpenSSH project, 2025. The primary source for when OpenSSH added hybrid key exchange and when it made it the default
whole page / 5 min
Checkpoint
Answer first, then compare with the model answer and score yourself against the rubric. Saved in this browser only.
01Recall
What is the basic mechanism difference between RFC 9370 and RFC 8784?
Model answer
RFC 9370 is a real hybrid KEM exchange: it adds PQC algorithms such as ML-KEM next to classical ECDH, up to 7 layers, with the IKE_INTERMEDIATE and IKE_FOLLOWUP_KE exchanges. RFC 8784 instead, with no PQC algorithm at all, mixes a symmetric preshared key (at least 256 bits of entropy), already shared over a secure channel, into the key derivation process.
02Recall
When did OpenSSH first add a PQC key exchange, when did it make one the default, and with which algorithm?
Model answer
OpenSSH 9.0 (April 2022) added the first PQ hybrid key exchange with sntrup761x25519-sha512. OpenSSH 9.9 (September 2024) added mlkem768x25519-sha256 (FIPS 203 ML-KEM-768). OpenSSH 10.0 (April 2025) made the latter the default.
03Scenario
A system administrator says 'Our SSH connections are already quantum-safe' without ever checking. Which command do you tell them to run, and for what?
Model answer
First, `ssh -Q kex | grep mlkem` to see that the installed OpenSSH supports mlkem768x25519-sha256. But that alone is not enough: they need to check with `ssh -vv` which algorithm is actually negotiated on a real connection, because even with a current version, a `KexAlgorithms` restriction in a configuration file or an older peer can silently fall back to a classical key exchange.
A complete answer includes
Your score: 0/3
04Hostile
An architect asks 'We use hybrid key exchange in IKEv2. Can't a MITM attacker downgrade it to a non-PQC mode?' Answer using the downgrade analysis in RFC 9370's own Appendix C.
Model answer
RFC 9370's Appendix C documents a rejected design in which the hybrid offer was sent directly in the first KE payload: with that approach an attacker could intervene and reply with an N(INVALID_KE_PAYLOAD) notification, downgrading the parties to classical Diffie-Hellman. RFC 9370's actual design prevents this, because the initiator must state its preferred post-quantum proposals in a separate notify payload rather than relying only on the KE payload; that stops an attacker from silently cancelling the whole PQC negotiation by getting one payload rejected.
A complete answer includes
Your score: 0/3
Project linkContributes to the protocol diversity section of Project 1, as a concrete example of the PQC transition status of protocols beyond TLS (IKEv2, SSH).