Ketan, I had this same question (on a different draft). If the failure is a result of an attempted attack, the fact that it failed cannot be observed from the outside. The traffic won't decrypt properly, which will be obvious for the recipient. Oracle attacks work like that - the attacker submits input and waits to see what is accepted. Notice of a failure tells them they got it wrong.
(I do still wonder about 'distinguished', and I didn't catch it on this draft... might be language from the FIPS spec) Deb On Sat, Jun 27, 2026 at 5:12 PM Kampanakis, Panos <kpanos= [email protected]> wrote: > 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]
