Summary

  • RFC 10042 defines three SSH key-exchange methods that combine ML-KEM with P-256, P-384 or X25519. It is an IETF Informational RFC authored by Panos Kampanakis, Douglas Stebila and Torben Hansen.
  • The hybrid server reply still contains a server public host key and a signature. SSH then runs a separate user-authentication protocol, so KEX, host identity and user identity need three distinct receipts.
  • An AWS SFTP debug example prints those layers separately: the hybrid KEX, the host-key algorithm and fingerprint, and later public-key user authentication. That trace is a better audit model than a single “quantum-safe SSH” badge.

Read an SSH verbose log slowly and the protocol resists the marketing shortcut. One line names the key-exchange algorithm. Another names the server's host-key algorithm and prints its fingerprint. Later, after new transport keys are active, a different line records how the user authenticated.

The connection may feel like one event to the person moving a file. Its security decisions are not interchangeable.

RFC 10042, published in August 2026, makes the first decision more durable against a future cryptographically relevant quantum computer. Kampanakis, Stebila and Hansen define three hybrid methods: mlkem768nistp256-sha256, mlkem1024nistp384-sha384 and mlkem768x25519-sha256. Each combines an ML-KEM component with a traditional elliptic-curve exchange.

That is an important answer to harvest-now-decrypt-later risk. An adversary can retain encrypted SSH traffic and hope that future computation breaks the traditional key establishment. The hybrid construction derives the session secret from post-quantum and classical contributions instead of trusting only one family.

It is also one answer to one question.

The host key did not disappear

RFC 10042's message diagram makes the boundary unusually hard to miss. The client sends its post-quantum and traditional ephemeral public material. The server returns its ML-KEM ciphertext and traditional ephemeral public key—but also K_S, the server's public host key, and a signature on the exchange hash.

The hybrid shared secret is calculated as a hash of the ML-KEM and classical secrets. The exchange hash covers that result, both sides' version and negotiation messages, the hybrid exchange values and the server host key. The server signs the hash with its host-key private key.

Those fields connect key exchange to server authentication without merging their responsibilities. The hybrid components help the parties derive fresh transport keys. The host-key signature tells the client which server claims the transcript. The client must still decide whether that key belongs to the intended host.

RFC 4253 makes the separation explicit before the hybrid messages begin. kex_algorithms and server_host_key_algorithms are different ordered lists in SSH_MSG_KEXINIT. The chosen KEX must be compatible with a host-key algorithm both sides accept. If no valid combination exists, the connection fails.

Trust does not follow from successful mathematics alone. A client may compare the host key with a local database, a pinned fingerprint or a certificate chain. RFC 4253 allows acceptance without verification but warns that doing so leaves the protocol insecure against active attacks. A post-quantum contribution cannot repair an ignored host-key warning.

The receipt for this layer therefore needs more than the KEX name. It needs the selected host-key algorithm, the fingerprint or certificate, the trust source, the verification result and the key-rotation policy. If the host signature remains classical, the report should say so. If the key changed unexpectedly, a hybrid transport secret is not permission to click through.

The user arrives after the transport

SSH then asks a question in the opposite direction. The client has evaluated the server. Now the server must decide whether a named user may access a service.

RFC 4252 defines that later authentication protocol above the transport layer. Public-key authentication is required for implementations; password and host-based methods are optional, and extensions can add others. A public-key request carries a user name, service name, algorithm, key and signature. The server checks whether the key is acceptable for that user and may demand further authentication before returning success.

This is not the same “public key” as the server host-key decision merely because both involve signatures. The principals, key stores and policies differ. A host key authenticates the server to the client. A user key helps authenticate a user to the server. Account state, authorised-key files, identity-provider policy, multifactor requirements, command restrictions and SFTP directory permissions live beyond the KEX method name.

The distinction matters during migration. An organisation may update its SSH libraries and preference lists so clients negotiate an RFC 10042 method while leaving host signatures and user credentials unchanged. That can be a rational sequence. It becomes misleading only when the first completed stage receives credit for the other two.

A production trace with three columns

An AWS Security Blog article about hybrid SFTP provides a concrete receipt anatomy. Its original 2023 example used pre-standardisation Kyber method names. A 5 September 2025 update says two AWS Transfer Family security policies moved to ML-KEM and lists the same three method names later published in RFC 10042.

The older trace should not be presented as an RFC 10042 session. Its value is structural. The debug output names a hybrid KEX, separately reports ssh-ed25519 as the host-key algorithm and prints the host fingerprint. Only later does it say the endpoint authenticated the user using publickey and opened the SFTP session.

That ordering turns an abstract standards boundary into an operator checklist:

  1. What hybrid method did the two endpoints actually negotiate?
  2. Which host key signed the exchange, and why did the client trust it?
  3. Which user method succeeded, for which account and under which authorization policy?

The first line cannot answer the second or third. The final “connected” line adds evidence that a channel opened, but it still does not prove every file permission, storage control, audit record or recovery path.

The update is also a reminder that migration has a software lifecycle. Experimental Kyber names yielded to standardised ML-KEM names. Clients and servers do not upgrade in perfect lockstep. Preference order, compatibility fallback, library version and policy selection decide which method runs on a particular connection. An IANA row marked SHOULD is an interoperability coordinate, not a census.

Kampanakis and the useful limit of a standard

Amazon Science describes Kampanakis as a principal security engineer at AWS working across applied cryptography, security automation and standards. In a 2023 AWS profile, he argued for inventorying asymmetric cryptography, testing post-quantum effects in use cases including SSH, and designing for algorithm agility. He also stressed the distance between a controlled proof of concept and long-term support at scale.

That biography helps explain why RFC 10042 is operationally useful, but it must not erase collective work. Stebila and Hansen are co-authors. The RFC credits implementation and review contributions from AWS, OpenSSH, PuTTY and other entities. NIST standardised ML-KEM. The IETF process and IANA registry provide the shared wire coordinates.

The useful limit is the achievement. RFC 10042 standardises a narrow exchange, its combiner, encodings, validation checks, method names and failure behaviour. It requires fresh ephemeral keypairs for every connection, forbids ML-KEM ciphertext-randomness reuse and specifies abort conditions for malformed lengths or failed decapsulation. Those details convert a general migration intention into something implementers can test against each other.

It does not need to standardise every trust store, account database, endpoint policy and recovery procedure to be valuable. Heng Lu's Minimum Initial Specification principle favours precisely this kind of boundary: define the smallest interoperable mechanism, then leave future deployment choices with the parties that run the systems.

Running-Code Primacy supplies the audit rule. Record the observed result, not the declaration. For SSH, that means client and server versions; offered and selected KEX lists; host-key algorithm and fingerprint; trust decision; cipher and MAC; SSH_MSG_NEWKEYS; user-authentication method; authorization result; channel or subsystem opened; rekey; fallback; failure; and the blind spots of the probe.

Three receipts do not diminish the hybrid exchange. They prevent its success from hiding unfinished work. RFC 10042 gives operators a stronger first column. A mature report keeps the other two columns visible until their own evidence arrives.

Sources