Hi Wang, Songbo, and all Thank you both for the feedback. Let me briefly share my thoughts on points:
I actually share the same skepticism regarding the implicit NONE. It does introduce potential security risks and potential downgrade vectors. My preference towards Consideration 1 (Duplicate Selection), as it resolves the parsing friction without weakening the cryptographic strength of the exchange. But consideration 2 I think is also useful as well with proper implementation like the local checks before the response. I will try to refine this part in next version. Regrading Interoperability, I think to ensure both sides are on the same page and prevent "invisible" fallback behaviors, the draft has mentioned a compatibility indication/messages sent from the responder back to the initiator whenever the extended policies are triggered. This gives peers full visibility into the path taken. I would highly welcome you and anyone else to contribute to, discuss, or refine this draft. I have set up a GitHub repository for collaborative editing. Please feel free to raise issues, submit texts, or open branches here: https://github.com/lihjacky/draft-on-ipsecme Looking forward to discussing this further with you. Best regards, Lun Li From: Songbo Bu <[email protected]> Sent: June 12, 2026, 9:35 To: [email protected]; [email protected] Cc: lilun (F) <[email protected]> Subject: RE: [IPsec] New I-D: draft-li-ipsecme-extensions-for-robust-negotiation// Re: Triggering discussion on RFC 9370 ADDKE algorithm selection and potential issues Hi Wang, Lun, I agree with this concern. I think the draft becomes much easier to review if the extended path is described as a deterministic responder algorithm, not as a collection of fallback heuristics. The way I would frame it is: 1. The responder first computes the strict RFC 9370 outcome, if one exists. 2. If no strict outcome exists, the responder may enter an explicitly configured extended-policy path. 3. That extended path still needs a deterministic selection rule for the same input, not implementation-local guesswork. 4. The output of the extended path must be checked against a local minimum-security policy before the responder accepts it. 5. The implementation should be able to report which path was used: strict RFC 9370, extended-policy accepted, or rejected. That keeps the compatibility goal, but avoids making fallback behavior invisible. It also gives the interop matrix a useful shape: same initiator proposal, same responder capability, strict outcome, extended outcome, selected path, and whether the local security floor permits it. I would be cautious about implicit NONE handling unless the draft makes the policy gate very explicit. Otherwise it may look like a robust-negotiation feature while actually changing the expected number or class of KEM contributions. Best, Songbo On Thu, 11 Jun 2026 21:19:31 +0000, Wang Xi [email protected]<mailto:[email protected]> wrote: 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]<mailto:[email protected]> Sent: Wednesday, June 10, 2026 6:50 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> [email protected]<mailto:[email protected]> Sent: June 5, 2026, 16:30 To: lilun (F) [email protected]<mailto:[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]<mailto:[email protected]> Sent: April 30, 2026 15:25 To: Valery Smyslov [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]> Sent: April 29, 2026 20:52 To: lilun (F) [email protected]<mailto:[email protected]>; Wang Guilin [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]> Sent: 24 Apr 2026 17:56 To: lilun (F) [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Tobias Brunner [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Wang Guilin [email protected]<mailto:[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]<mailto:[email protected]> Sent: Friday, 24 April 2026 4:12 pm To: [email protected]<mailto:[email protected]>; Tobias Brunner [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[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]<mailto:[email protected]> Sent: April 16, 2026 18:54 To: lilun (F) [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> IPsec mailing list – [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> IPsec mailing list – [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> IPsec mailing list – [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> IPsec mailing list – [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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]
