Hi Lun, Thanks for sharing the draft.
I wanted to raise one question regarding the security implications of introducing an extended-policy fallback in addition to the strict RFC 9370 behavior. My main concern is not about classical downgrade attacks in the traditional sense, but rather whether the introduction of an additional “extended-policy outcome” path may affect the determinism of the negotiation outcome defined in RFC 9370. Particularly, for a given initiator proposal and responder capability, the draft seems to allow two semantically different classes of outcomes: a strict RFC 9370-compliant deterministic selection, and a policy-driven fallback selection (e.g., duplicate resolution or implicit NONE handling) If different implementations apply different fallback heuristics or thresholds, this could lead to situations where the same input results in different security-relevant outcomes across implementations. I am wondering whether this introduces a potential selection surface where an active attacker could influence which valid processing path is taken, for example by shaping proposals that trigger fallback behavior in some implementations but not others. To be clear, I am not suggesting that this directly weakens the cryptographic strength of RFC 9370, but rather that it may complicate the assumption of a single deterministic security outcome per valid input, which is a key property in many IKEv2 negotiation designs. Happy to discuss further or help refine the interop matrix idea if useful. Best, Wang Xi -----Original Message----- From: Songbo Bu <[email protected]> Sent: Wednesday, June 10, 2026 6:50 PM To: [email protected] Cc: [email protected] Subject: [IPsec] New I-D: draft-li-ipsecme-extensions-for-robust-negotiation// Re: Triggering discussion on RFC 9370 ADDKE algorithm selection and potential issues Hi Lun, Thanks for posting this. I think the draft is useful because it turns a real configuration/interoperability failure into something the WG can reason about. One point that might make the mechanism easier to review: I would separate the "find a valid RFC 9370 outcome" case from the "compatibility fallback" case. My read is: - First, the responder should try a holistic selection over the ADDKE transform types and prefer a valid, non-duplicated set when one exists. - Only if no such set exists, local compatibility policy could decide whether to accept a weaker outcome, such as duplicate use of the same KEM or an implicit NONE. - That fallback should be gated by an explicit local minimum-security policy, so the responder never silently turns a multi-KEM intent into something below its configured floor. This framing may also make Section 6 easier to turn into an interop matrix: initiator proposal, responder capability, strict RFC 9370 outcome, extended-policy outcome, and the security threshold that allowed or rejected it. If useful, I can help sketch that matrix or a short responder-processing checklist for the Vienna discussion. Best, Songbo Bu On Tue, 9 Jun 2026 07:04:15 +0000, "lilun (F)" <[email protected]> wrote: > Dear all, > > I've posted a new individual draft to address some robust negotiation issues > found during multi-KEM migration in IKEv2. > > Title: Consideration of Robust Multi-KEM Negotiation within IKEv2 > URL: > https://datatracker.ietf.org/doc/draft-li-ipsecme-extensions-for-robus > t-negotiation/ > > The draft discusses scenarios where initiators send redundant or overlapping > KEM algorithm lists across different ADDKE transform types (RFC 9370) based > on our PoC best practice. To prevent interoperability fragmentation and > unexpected negotiation failures on the wire, this document introduces > deterministic extended selection logic for responders (such as duplicate > selection). > > Please review the document and feel free to share your thoughts on the > mailing list. > > I would also like to be considered having chance to request a presentation > slot at the upcoming Vienna meeting to introduce this I-D to the group. > > Regards, > > Lun Li > > > -----Original message----- > > From: [email protected] <[email protected]> > > Sent: June 5, 2026, 16:30 > > To: lilun (F) <[email protected]> > > Subject: New Version Notification for> > > draft-li-ipsecme-extensions-for-robust-negotiation-00.txt > > > > A new version of Internet-Draft > > draft-li-ipsecme-extensions-for-robust-negotiation-00.txt has been > > successfully submitted by Lun Li and posted to the IETF repository. > > > > Name: draft-li-ipsecme-extensions-for-robust-negotiation > > Revision: 00 > > Title: Consideration of Robust Multi-KEM Negotiation within IKEv2 > > Date: 2026-06-03 > > Group: Individual Submission > > Pages: 11 > > URL: > > https://www.ietf.org/archive/id/draft-li-ipsecme-extensions-for-robu > > st-negot > > iation-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-li-ipsecme-extensions-for-rob > > ust-negoti > > ation/ > > HTMLized: > > https://datatracker.ietf.org/doc/html/draft-li-ipsecme-extensions-fo > > r-robust- > > negotiation > > > > > > Abstract: > > > > RFC 9370 specifies a framework for multiple additional key exchanges > > (ADDKE) in the Internet Key Exchange Protocol Version 2 (IKEv2) to > > support post-quantum cryptography migration. Under this framework, > > an initiator can propose multiple ADDKE transform types. In > > deployment scenarios, initiators may send proposals that contain > > redundant or overlapping lists of Key Encapsulation Mechanism (KEM) > > algorithms across different ADDKE transform types. This contribution > > discusses the implications of these proposals and specifies extended > > procedures for handling proposed transforms, which may improve > > negotiation robustness and interoperability by allowing the > > responder to select a valid set of algorithms without altering the > > security properties defined in RFC 9370. > > > > > > > > The IETF Secretariat > > > > > -----Original message----- > > From: Lilun (F) <[email protected]> > > Sent: April 30, 2026 15:25 > > To: Valery Smyslov <[email protected]>; [email protected] > > Subject: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE > > algorithm selection and potential issues.> Hi Valery, > > > > Thanks for the explain. I think generally the ADDKE algorithm > > selection is an interesting topic and worth to re-visit. > > I am about to prepare an individual draft to further illustrate this > > topic for the reference. > > > > Regards, > > Lun > > > > > -----Original message----- > > > From: Valery Smyslov <[email protected]> > > > Sent: April 29, 2026 20:52 > > > To: lilun (F) <[email protected]>; Wang Guilin > > > <[email protected]>; [email protected] > > > Subject: RE: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE > > algorithm > > > selection and potential issues> > > > Hi Lun, > > > > > > The intended use of multiple ADDKE transforms was that each of > > > these transforms would contain KE methods based on different > > > mathematical properties. For example, the initiator can put all > > > lattice-based KEMs to ADDKE1, all code-based KEMs to ADDKE2 etc. > > > (we have plenty of spare transforms for the future). > > > > > > It is a little point for the initiator to populate all ADDKE > > > transforms with the > > same > > > set of algorithms - just a waste of message space in IKE_SA_INIT, > > > where it is often limited. It is the responder who can have a > > > policy allowing *any* supported KEM in *any* ADDKE, since this > > > policy is not transferred on the wire and > > does not > > > eat space. > > > In this case, the responder does not care the order of KEMs, but > > > should > > make > > > sure that > > > a needed set of KEMs is proposed. > > > > > > But this is just a good way of using RFC 9370, the specification > > > does not > > prohibit > > > other scenarios. > > > The only restriction is a prohibition of multiple use of the same > > > KE method, > > since > > > it makes no sense > > > from security PoV and is a waste of resources. > > > > > > Regards, > > > Valery. > > > > > > > > > > Hi Guilin, > > > > > > > > I agree with your assessment of the current RFC 9370 text. > > > > redundant > > > proposals don't provide additional security. > > > > > > > > I think the motivation for bringing this to the WG is the gap > > > > between the > > > specification and best practice reflecting, > > > > particularly in large-scale deployments. > > > > > > > > In practice, IKEv2 configurations are often managed by > > > > developers who > > might > > > perhaps populate ADDKE slots with > > > > the same algorithm list. Currently, this redundancy causes a > > > > hard > > negotiation > > > failure. I hope to raise is whether we > > > > should allow the responder to be more resilient. If a secure > > > > connection > > can still > > > be established. > > > > > > > > Furthermore, different implementations may have handled these > > > > edge > > cases in > > > different ways to consider > > > > robustness. However, this could potentially lead to interoperability > > > > issues. > > it is > > > not to encourage redundant configs > > > > in specification level, but to explore if the protocol can be > > > > more resilient > > during > > > PQC migration. > > > > > > > > Regards, > > > > > > > > Lun > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Wang Guilin <[email protected]> > > > > Sent: 24 Apr 2026 17:56 > > > > To: lilun (F) <[email protected]>; [email protected]; Tobias > > > > Brunner > > > <[email protected]> > > > > Cc: [email protected]; Wang Guilin > > > > <[email protected]> > > > > Subject: RE: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE > > algorithm > > > selection and potential issues > > > > As I understand, your case "ADDKE1 [A, B], ADDKE2 [A, B], ADDKE3 > > > > [A, > > B]" is > > > not allowed mainly because, from > > > > the security view point, such proposal does not enhance security > > > > while > > > increases the complexity for both side (to > > > > run the same algorithm twice or more). > > > > > > > > For such a proposal, as requiring to select select one algorithm > > > > in each > > ADDKE, > > > the responder has to select > > > > something like "ADDKE1 [A], ADDKE2 [B], ADDKE3 [A]". However, > > > > such > > an > > > answer is not allowed according to > > > > 2.2.1 in RFC 9370. So, a failure will happen. > > > > > > > > 2.2.1 > > > > "The responder performs the negotiation using the standard IKEv2 > > procedure > > > described in Section 3.3 of > > > > [RFC7296]. However, for the ADDKE Transform Types, the > > responder's > > > choice MUST NOT contain duplicated > > > > algorithms (those with an identical Transform ID and > > > > attributes), except > > for the > > > Transform ID of NONE." > > > > > > > > So, to prepare aproposal, the initiator may need to do as follows: > > > > > > > > - If the initiator wants the responder to select either A or B, > > > > the proposal > > should > > > be: "ADDKE1 [A, B]". > > > > - If the initiator wants the responder to select A and B, the > > > > proposal > > should be: > > > "ADDKE1 [A], ADDKE2 [B] ". > > > > - If the initiator wants the responder to select A OR (A and B), > > > > the > > proposal > > > should be: "ADDKE1 [A], ADDKE2 [B, > > > > None]". > > > > - If the initiator wants the responder to select None OR A OR B > > > > OR (A and > > B), > > > the proposal should be: "ADDKE1 > > > > [A, None], ADDKE2 [B, None]". > > > > - ... > > > > > > > > Guilin > > > > > > > > -----Original Message----- > > > > From: lilun (F) <[email protected]> > > > > Sent: Friday, 24 April 2026 4:12 pm > > > > To: [email protected]; Tobias Brunner <[email protected]> > > > > Cc: [email protected] > > > > Subject: [IPsec] Re: Triggering discussion on RFC 9370 ADDKE > > > > algorithm > > > selection and potential issues > > > > > > > > Hi Thanks Tobias, and all work group, > > > > > > > > Thank you for the reply. I think strongSwan already does an > > > > excellent job > > > implementing RFC 9370, and your > > > > example illustrates the cases we are encountering. > > > > > > > > Actually but, my main point is whether we could explore a > > > > potential > > > specification draft/update/extension to handle > > > > these redundant scenarios more gracefully. Reviewing some of our > > > > failed > > test > > > cases, I am wondering if we could > > > > relax or clarify the restrictions. > > > > > > > > In practice, many developers might configure ADDKEs by simply > > > > filling > > them > > > with the exact same list of supported > > > > algorithms. For example, an initiator might send: > > > > ADDKE1 [A, B], ADDKE2 [A, B], ADDKE3 [A, B] Currently, this > > > > redundant > > > configuration leads to negotiation failure. > > > > It would be much more robust if the responder could tolerate the > > redundancy > > > and intelligently select algorithms— > > > > for example, selecting A for ADDKE1, B for ADDKE2, and another A > > > > for > > > ADDKE3—thus still resulting in a > > > > successful hybrid exchange. > > > > > > > > If there is interest in exploring this in the Work Group for > > > > algorithm > > selection > > > issues and more, I would be very > > > > happy to request a presentation slot at IETF 126 to elaborate > > > > above > > content > > > and some deep thinking. > > > > > > > > Best regards, > > > > > > > > Lun Li > > > > > > > > -----Original Message----- > > > > From: Tobias Brunner <[email protected]> > > > > Sent: April 16, 2026 18:54 > > > > To: lilun (F) <[email protected]>; [email protected] > > > > Cc: [email protected]; [email protected] > > > > Subject: Re: [IPsec] Triggering discussion on RFC 9370 ADDKE > > > > algorithm > > > selection and potential issues On > > > > 16.04.26 12:18, lilun (F) wrote: > > > > > Hi Everyone, > > > > > > > > > > Following our earlier research in the PQUIP WG regarding PQC > > migration > > > > > in telecom systems, our team have recently been implementing > > > > > IKEv2 migration based on RFC 9370. During this process, we > > > > > encountered > > some > > > > > negotiation failures related to ADDKEs that I would like to > > > > > bring to the WG's attention for discussion. > > > > > > > > > > During our PoC testing, we observed that IKE configuration > > > > > errors— specifically, configuring the same algorithm > > > > > redundantly in ADDKE payloads during IKE negotiation—frequently lead > > > > > to negotiation failures. > > > > > > > > > > According to RFC 9370, Section 2.2.1 (which also references > > > > > RFC 7296, Section 2.7), the implementation shall be strictly limited: > > > > > > > > > > /"the responder MUST select one of the algorithms proposed > > > > > using this type... the responder's choice MUST NOT contain > > > > > duplicated algorithms (those with an identical Transform ID > > > > > and attributes), except for the Transform ID of NONE."/ > > > > > > > > The important part there is "responder's choice". It's perfectly > > > > fine to > > > configure as well as send the same > > > > algorithms in ADDKEs as initiator. > > > > The responder just has to make sure its proposal selection > > > > process does > > > result in a unique algorithm for each > > > > ADDKE (except for NONE). > > > > > > > > > Based on feedback from our testing, some errors may be > > > > > occurred frequently in the configuration, and they were negotiation > > > > > failed. > > > > > After troubleshooting, We found that the error was due to the > > > > > same algorithm being configured in ADDKEs during IKE in a > > > > > redundance. For example, placing ML-KEM-768 in multiple ADDKEs > > > > > > > > > > I would like to start a discussion on whether these strict in > > > > > 2.2.1 limitations for ADDKEs could have consideration for > > > > > future releases (for instance, in PQC-specific profiles like > > > > > ML-KEM). Considering the > > > > > real- world possibility of configuration redundancies. > > > > > > > > > > Interestingly, also as part of our research verification, we > > > > > found that some open-source implementations (e.g., strongSwan) > > > > > handle > > ADDKE > > > > > differently. Instead of strict responder selection, the > > > > > algorithm negotiation is often simplified to finding the > > > > > intersection of multiple ADDKEs between peers. > > > > > > > > Yes, we have simplified the process a bit in so far that we only > > > > check > > individual > > > ADDKEs (sequentially) and avoid > > > > duplicates overall. So we currently can't handle situations like > > ADDKE1[A, B], > > > ADDKE2[B, C] with a local config of > > > > ADDKE1[B, A], ADDKE2[B, A]. We'd select ADDKE1[B] (preferring > > > > the > > local > > > config and order by default) but that > > > > prevents selecting it for ADDKE2, so no valid proposal results. > > > > However, > > > ADDKE1[A], ADDKE2[B] would > > > > technically be acceptable by both peers (in this particular > > > > example > > disabling > > > prefer_configured_proposals would > > > > make it work). > > > > > > > > Regards, > > > > Tobias > > > > _______________________________________________ > > > > 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] > > > > _______________________________________________ > > 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] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected] *** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. *** _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
