IETF Last Call Review of draft-ietf-sshm-mlkem-hybrid-kex-07
review-ietf-sshm-mlkem-hybrid-kex-07-opsdir-lc-graf-2026-01-01-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: [draft-ietf-sshm-mlkem-hybrid-kex-07]

- Reviewer: [Thomas Graf]

- Review Date: [01.01.2026]

- Intended Status: [Informational]

This document defines Post-Quantum Traditional (PQ/T) Hybrid key exchange
methods using the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)
standard and traditional Elliptic-curve Diffie–Hellman (ECDH) key exchange
schemes for extending the SSH Transport Layer Protocol.

I have reviewed the document and its references. I am not a cryptography expert
and therefore won't be able to judge and comment on the security related
statements. My focus is primarily on operations and manageability.

The document is straightforward and very well written. Therefore my comments
are rather minor.

---

## Summary

Choose one:

- Ready: No issues found. This document is ready for publication.

## General Operational Comments Alignment with RFC 5706bis

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis gives
guidance on operations and manageability of new protocols or extension.

In the following sentence

   This document addresses the problem by extending the SSH Transport
   Layer Protocol [RFC4253] key exchange

I suggest to reference https://datatracker.ietf.org/doc/html/rfc4253#section-7
specifically and consider in the document to briefly mention the migration path
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis-01#section-4.3
to ML-KEM.

In the following sentence

   An implementation adhering to [RFC4253] must be able to support
   packets with an uncompressed payload length of 32768 bytes or less
   and a total packet size of 35000 bytes or less (including
   'packet_length', 'padding_length', 'payload', 'random padding', and
   'mac').

I also suggest to reference
https://datatracker.ietf.org/doc/html/rfc4253#section-6.1 specifically. I
understood that the section 2.3 defined methods does not impose such issues
while other post-quantum key exchange schemes might impose such problems.

In the Acknowledgements section the authors describe that there are existing
implementations. Please consider writing a "Implementation Status" section as
described in https://datatracker.ietf.org/doc/html/rfc7942#section-2 or/and
link the open-source implementation in the data tracker.

---