The draft was withdrawn on 2025-10-02 and there hasn't been another proposal for TLS 1.4.
TLS 1.3 is the latest version of the protocol and will have PQC in the form of Merkle Tree Certificates as well as currently supporting traditional signed certificates using PQC (RFC 9881: Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) | RFC Editor).
Edit: TLS 1.3 currently supports post quantum key exchange and this is widely deployed in the form of X25519MLKEM.
There are currently no active plans for TLS 1.4, and that draft isn’t from the TLS working group.
Thank you for sharing!
Small addition (all of the above is correct): What's currently deployed in TLS 1.3 KEX is a "hybrid" consisting of both a "traditional" (discrete logarithm problem) algorithm and a post-quantum algorithm (module learning with errors problem) - X25519 and ML-KEM. While this does provide post-quantum security, it does involve legacy cryptography. The idea is to have security from both: If the post quantum part turns out to be bad, you still have the existing (forward) secrecy from X25519 as long as that cannot be broken. Vice versa, if the X25519 part is broken, you are still secure as long as ML-KEM holds. This enabled rapid deployment, as the risk is low. In a ([not so] near?) future, when X25519 is actually broken in the wild, TLS authors may consider to ditch it for a true PQ-only handshake (maybe even with PFS at some point? Still hoping...). But for now the hybrid is perfectly fine and secure.
Not sure what you mean with a PQ-only handshake "even with PFS at some point" ?
ML-KEM provides forward secrecy just like ECDHE (incl. X25519) and DHE do, as they all establish ephemeral symmetric encryption keys for that session only. PFS means that an eventual disclosure or break of the server's private key (the one for the certificate) won't allow decryption of earlier sessions, as was the case with RSA encryption (TLS_RSA_* ciphers).
I misremembered that ML-KEM could reuse public/private keys, same as in static ECDH that TLS has had for many years now. This improves performance somewhat, but it looses PFS if you manage to break an earlier share that is then reused (or was reused previously). This was mentioned in certain early drafts (ML-KEM Security Considerations) and I somehow thought that it ended up in draft-kwiatkowski-tls-ecdhe-mlkem/draft-ietf-tls-ecdhe-mlkem. But I just re-checked the RFC and it does not make explicit mentions of this.
Yes, ML-KEM can reuse keys (like any algorithm). But its keygen is so cheap (faster than X25519 even) that there's no reason to.
If there is a TLS 1.4, it will have support for PQC but we don't have to update TLS in order to support PQC, we can simply use TLS 1.3 with either a PQC key or a hybrid PQC + ECC key.