[auth48] Re: Final Review: RFC-to-be 10042 (draft-ietf-sshm-mlkem-hybrid-kex) in XML

[Douglas Stebila <[e-mail]>]

I approve.  Thanks all!

Douglas


On Aug 28, 2026, at 9:55 AM, Hansen, Torben <[e-mail]> wrote:

Approved

Thanks!

/Torben

From: Kampanakis, Panos <[e-mail]>
Date: Thursday, August 27, 2026 at 8:21 PM
To: Kaelin Foody <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Hansen, Torben <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [EXTERNAL] Final Review: RFC-to-be 10042 (draft-ietf-sshm-mlkem-hybrid-kex) in XML

Hi Kaelin,
All the changes look fine. Approved from my side.

Torben, Douglas?


-----Original Message-----
From: Kaelin Foody <[e-mail]>
Sent: Thursday, August 27, 2026 2:51 PM
To: Kampanakis, Panos <[e-mail]>; [e-mail]; [e-mail]; Hansen, Torben <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [EXTERNAL] Final Review: RFC-to-be 10042 (draft-ietf-sshm-mlkem-hybrid-kex) in XML

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hi authors,

Thank you for your reply. We have updated the files accordingly and posted them at the end of this email.

Upon careful review, please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each party listed on the Final Review status page for this document prior to moving forward in the publication process.

The Final Review status of your document is available here:
https://queue.rfc-editor.org/final-review/rfc10042

-- FILES (please refresh): --

The updated files have been posted here:
https://www.rfc-editor.org/authors/rfc10042.txt
https://www.rfc-editor.org/authors/rfc10042.pdf
https://www.rfc-editor.org/authors/rfc10042.html
https://www.rfc-editor.org/authors/rfc10042.xml

Diff files showing changes made during Final Review:
https://www.rfc-editor.org/authors/rfc10042-auth48diff.html
https://www.rfc-editor.org/authors/rfc10042-auth48rfcdiff.html (side by
side)

Diff files showing all changes:
https://www.rfc-editor.org/authors/rfc10042-diff.html
https://www.rfc-editor.org/authors/rfc10042-rfcdiff.html (side by side)

Thank you,

Kaelin Foody
RFC Production Center


On 8/24/26 11:27 PM, Kampanakis, Panos wrote:
> Dear RFC Production Center,
>
> Answers in line with PK>
>
> Thank you
>
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Monday, August 24, 2026 6:20 PM
> To: Kampanakis, Panos <[e-mail]>; [e-mail];
> Hansen, Torben <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [EXTERNAL] Final Review: RFC-to-be 10042
> (draft-ietf-sshm-mlkem-hybrid-kex) in XML
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Authors,
>
> While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in the source file.
>
> 1) <!-- [rfced] Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations should be expanded in titles of RFCs when possible. Can any abbreviations be expanded in the title below?
>
> Original:
>     PQ/T Hybrid Key Exchange with ML-KEM in SSH
>
> Perhaps:
>     Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange with
>     the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for
> Use in SSH
> -->
>
> PK> Yes, but I suggest removing the text in parenthesis to keep it shorter. The abbreviations are defined in the text as well.
>
> 2) <!-- [rfced] We note that the reference [I-D.ietf-pquip-pqc-engineers] (now published as RFC 9958) uses "harvest now, decrypt later" rather than "harvest-now-decrypt-later". May we update for consistency?
>
> Original:
>     This kind of attack is known as a 'harvest-now-decrypt-later' attack
>     [I-D.ietf-pquip-pqc-engineers].
>
> Perhaps:
>     This kind of attack is known as a 'harvest now, decrypt later' attack
>     [RFC9958].
> -->
>
> PK> Yes
>
> 3) <!-- [rfced] We have updated this list to be a bulleted list.  It was originally included as artwork.  Please review and let us know if any updates are needed.
>
> <artwork align="left" name="" type="" alt=""><![CDATA[
>        mlkem768nistp256-sha256
>        mlkem1024nistp384-sha384
>        mlkem768x25519-sha256
> ]]></artwork>
> -->
>
> PK> That is fine.
>
> 4) <!-- [rfced] May we add "that is" to the text below (to appear before "always big-endian")?
>
> Original:
>     Specifically for K_CL, the conversion from mpint to a byte array is done by
>     taking the mpint that the corresponding standalone key exchange method
>     would have output and re-encoding it as a fixed-size (32 bytes for
>     Curve25519 and secp256r1 or 48 bytes for secp384r1) byte array always big-
>     endian.
>
> Perhaps:
>     Specifically for K_CL, the conversion from mpint to a byte array is done by
>     taking the mpint that the corresponding standalone key exchange method
>     would have output and re-encoding it as a fixed-size (32 bytes for
>     Curve25519 and secp256r1 or 48 bytes for secp384r1) byte array that is
>     always big-endian.
> -->
>
> PK> That looks fine.
>
> 5) <!-- [rfced] We updated the IANA Considerations to include a table showing the values being registered.  Please review and let us know if you prefer otherwise.
>
> Original:
> 5.  IANA Considerations
>
>     This memo requests IANA to register new method names
>     "mlkem768nistp256-sha256", "mlkem1024nistp384-sha384", and
>     "mlkem768x25519-sha256" in the "Key Exchange Method Names" registry
>     for SSH [IANA-SSH] with a "Reference" field to this RFC and the "OK
>     to implement" field of "SHOULD".
>
> Current (horizontal lines removed so this text could be included in comments):
>     IANA has registered the following method names in the "Key Exchange
>     Method Names" registry within the "Secure Shell (SSH) Protocol
>     Parameters" registry group.
>
>          +==========================+===========+=================+
>          | Method Name              | Reference | OK to Implement |
>          +==========================+===========+=================+
>              | mlkem768nistp256-sha256  | RFC 10042 | SHOULD          |
>
>          | mlkem1024nistp384-sha384 | RFC 10042 | SHOULD          |
>
>          | mlkem768x25519-sha256    | RFC 10042 | SHOULD          |
>
>                    Table 1: New Key Exchange Method Names
> -->
>
> PK> That is fine.
>
> 6) <!-- [rfced] May we add "to be" to appear before "IND-CPA and IND-CCA2 secure" in the text below?
>
> Original:
>     [PQ-PROOF2] discusses how the key combination to
>     derive K and the derivation of SSH symmetric keys in this document
>     can be proven IND-CPA and IND-CCA2 secure with some assumptions.
>
> Perhaps:
>     [PQ-PROOF2] discusses how the key combination
>     to derive K and the derivation of SSH symmetric keys in this document
>     can be proven to be IND-CPA and IND-CCA2 secure with some assumptions.
> -->
>
> PK> That is fine.
>
> 7) <!-- [rfced] References:
>
> a) We note that [I-D.hoffman-c2pq] and [RFC4086] are included in the References section, but are not cited in the text of this document. Should these two references be removed?
>
> PK> Yes, please remove them.
>
> b) FYI - We updated the date for the reference [NIST_PQ] to match what the date provided at the URL.
> Please review and let us know any objections.
>
> PK> Should it be 2026?
> PK> https://csrc.nist.gov/projects/post-quantum-cryptography
>
> c) FYI - The original URL for the reference [NIST-SP800-186] pointed to a withdrawn draft. We have updated it to the correct final publication URL.
> -->
>
> PK> That is great.
>
>
> 8) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication.
> -->
>
> PK> Yes, all EDNOTEs are old and addressed.
>
> 9) <!-- [rfced] Please review each instance of the artwork and sourcecode element in this document.  In some cases, we updated artwork to sourcecode to match handling in other documents.  However, in cases where we were unsure, we left the item marked as artwork (e.g., Section 2.5).
>
> Please consider whether any artwork or sourcecode element should be (re)tagged.  In addition, if sourcecode is correct, please let us know if a type should be set (see the list of types defined to date at https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)  Note that it is acceptable for the type to be empty (i.e., type="").
> -->
>
> PK> They look fine, but
>
> string V_C, client identification string (CR and LF excluded) [...]
>
> Should also be sourcecode, not artwork to match the rest.
>
>
> 10) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online Style Guide
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed.  Updates of this nature typically result in more precise language, which is helpful for readers.
>
> Relatedly, please consider whether instances of "tradition"
> ("traditionally", "traditional", etc.) should be updated for clarity.
> While the NIST website
> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-
> research-library/nist-technical-series-publications-author-instruction
> s#table1> indicated that this term is potentially biased, it is also
> ambiguous.
> "Tradition" is a subjective term, as it is not the same for everyone.
> -->
>
> PK> Nothing else is necessary.
>
>
> Thank you.
>
> RFC Production Center
>
>
>
> On Aug 24, 2026, at 3:10 PM, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> RFC Author(s):
> --------------
>
> Final Review for RFC-to-be 10042 <draft-ietf-sshm-mlkem-hybrid-kex>
>
> Your document is now available for Final Review (previously AUTH48). Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies; see the Unavailable Authors section (https://authors.ietf.org/rfc-publication-process#unavailable-authors)
>
> You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>     Please review and resolve any questions raised by the RFC Editor
>     that have been included in the XML file as comments marked as
>     follows:
>
>     <!-- [rfced] ... -->
>
>     These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>     Please ensure that you review any changes submitted by your
>     coauthors.  We assume that if you do not speak up that you
>     agree to changes submitted by your coauthors.
>
> *  Content
>
>     Please review the full content of the document, as this cannot
>     change once the RFC is published.  Please pay particular attention to:
>     - IANA considerations updates (if applicable)
>     - contact information
>     - references
>
> *  Copyright notices and legends
>
>     Please review the copyright notice and legends as defined in
>     RFC 5378 and the Trust Legal Provisions
>     (TLP – https://trustee.ietf.org/license-info)
>
> *  Semantic markup
>
>     Please review the markup in the XML file to ensure that elements of
>     content are correctly tagged.  For example, ensure that <sourcecode>
>     and <artwork> are set correctly.  See details at
>     <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>     Please review the PDF, HTML, and TXT files to ensure that the
>     formatted output, as generated from the markup in the XML file, is
>     reasonable.  Please note that the TXT will have formatting
>     limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using 'REPLY ALL' as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>     *  your coauthors
>
>     *  [e-mail] (the RPC team)
>
>     *  other document participants, depending on the stream (e.g.,
>        IETF Stream participants are your working group chairs, the
>        responsible ADs, and the document shepherd).
>
>     *  [e-mail], which is an archival mailing list
>        to preserve discussion about the document while in the RPC editorial
>        queue; it is not an active discussion list:
>
>       *  More info:
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxI
> Ae6P8O4Zc
>
>       *  The archive itself:
>          https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>       *  Note: If only absolutely necessary, you may temporarily opt out
>          of the archiving of messages (e.g., to discuss a sensitive matter).
>          If needed, please add a note at the top of the message that you
>          have dropped the address. When the discussion is concluded,
>          [e-mail] will be re-added to the CC list and
>          its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
>   — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes.  Information about stream managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication.  Please use 'REPLY ALL', as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>     https://www.rfc-editor.org/authors/rfc10042.xml
>     https://www.rfc-editor.org/authors/rfc10042.html
>     https://www.rfc-editor.org/authors/rfc10042.pdf
>     https://www.rfc-editor.org/authors/rfc10042.txt
>
> Diff file of the text:
>     https://www.rfc-editor.org/authors/rfc10042-diff.html
>     https://www.rfc-editor.org/authors/rfc10042-rfcdiff.html (side by
> side)
>
> Diff of the XML:
>     https://www.rfc-editor.org/authors/rfc10042-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> Details on the status of your Final Review are here:
>     https://queue.rfc-editor.org/final-review/rfc10042/
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC 10042 (draft-ietf-sshm-mlkem-hybrid-kex)
>
> Title            : PQ/T Hybrid Key Exchange with ML-KEM in SSH
> Author(s)        : P. Kampanakis,
>                     D. Stebila,
>                     T. Hansen
> WG Chair(s)      : Stephen Farrell, Job Snijders
> Area Director(s) : Deb Cooley, Christopher Inacio