[OPS-DIR]Re: draft-ietf-sshm-mlkem-hybrid-kex-07 ietf last call Opsdir review

[[e-mail]]

Hi Thomas, 

Thank you for the review. I see that the authors published -08 with you review in mind.

FYI, I balloted "No Objection" right now: https://mailarchive.ietf.org/arch/msg/ssh/rDbAsDIqaT-b-NV3y0I7XfbtpH4/

Cheers,
Med

> -----Message d'origine-----
> De : Thomas Graf via Datatracker <[e-mail]>
> Envoyé : jeudi 1 janvier 2026 11:52
> À : [e-mail]
> Cc : [e-mail]; last-
> [e-mail]; [e-mail]
> Objet : [OPS-DIR]draft-ietf-sshm-mlkem-hybrid-kex-07 ietf last
> call Opsdir review
> 
> 
> Document: draft-ietf-sshm-mlkem-hybrid-kex
> Title: PQ/T Hybrid Key Exchange with ML-KEM in SSH
> Reviewer: Thomas Graf
> Review result: Ready
> 
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fdraft-opsarea-
> rfc5706bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3480
> b2d745ff465e363508de4923ca8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639028615225420886%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=xh5L17iezU3HzdP%2FHujNXNCMaAvu0wjy2
> 1aG5yY0C1o%3D&reserved=0.
> 
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-
> rfc5706bis&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3480b2d
> 745ff465e363508de4923ca8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
> C0%7C639028615225443850%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
> fQ%3D%3D%7C0%7C%7C%7C&sdata=5aOhxCtLUHPgSCoLgllAK9HDodlmwOZklwp5ez
> Eiw5E%3D&reserved=0 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4253%23section-
> 7&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3480b2d745ff465e
> 363508de4923ca8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390
> 28615225456944%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=E2mbOmfQpTHPZr8IaTxKvN3Hh%2F2a452jp696ko5Y71k%3
> D&reserved=0
> specifically and consider in the document to briefly mention the
> migration path
> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-opsawg-rfc5706bis-
> 01%23section-
> 4.3&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3480b2d745ff46
> 5e363508de4923ca8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 9028615225466377%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3
> D%7C0%7C%7C%7C&sdata=%2BVTdd6hR6R2nTVI04z%2FDtE2loEpJGlK5%2F49GldQ
> 0czo%3D&reserved=0
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4253%23section-
> 6.1&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3480b2d745ff46
> 5e363508de4923ca8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 9028615225475562%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3
> D%7C0%7C%7C%7C&sdata=1DR%2BMiOz%2Bcaut5v%2ByM1WSSmZ9ZkBEnfKpvXGbMp
> Q%2Fac%3D&reserved=0 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7942%23section-
> 2&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C3480b2d745ff465e
> 363508de4923ca8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390
> 28615225484427%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlY
> iOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%
> 7C0%7C%7C%7C&sdata=y86JkW6N88uGK9CfH2cKj1Tr%2BEQ3T%2F2%2FO9fdbrbBr
> GY%3D&reserved=0 or/and link the open-source implementation in the
> data tracker.
> 
> ---
> 
> 
> _______________________________________________
> OPS-DIR mailing list -- [e-mail] To unsubscribe send an
> email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.