Regarding your question, indeed ML-KEM is unique in that way because it does not explicitly reject the decapsulation, but it implicitly does it by producing a value (that is wrong in the case of an error) which will be identified as non-matching later. In other words, ML-KEM was chose to not explicitly reject which is a little different that the general definition in a KEM.
I also fixed the TBDs in the IANA section. -----Original Message----- From: Ketan Talaulikar via Datatracker <[email protected]> Sent: Friday, June 26, 2026 9:03 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] [IPsec] Ketan Talaulikar's No Objection on draft-ietf-ipsecme-ikev2-mlkem-07: (with COMMENT) 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. Ketan Talaulikar has entered the following ballot position for draft-ietf-ipsecme-ikev2-mlkem-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. I have one question and one comment that I would like to share for your consideration. 1) section 1.1 - the following two statements seem somewhat contradicting? ".. or in some rare cases a distinguished error value." "Note that ML-KEM's Decaps routine uses implicit rejection and will not return a distinguished error value." 2) IANA Considerations - This is a minor thing; I believe these values are already allocated by IANA and only this document references needs to be update to RFC-TBD? If so, please consider updating the text that way. _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
