Hi Songbo, Lun, Thanks for the detailed PR and the clear description.
This direction makes sense to me, too. In particular, I think making the responder behavior deterministic and explicitly visible, while subject to policy-controlled disclosure, is helpful for interoperability. The PR looks like a useful step towards clarifying the behavior without changing the overall intent of the draft. It looks good to me. Happy to continue the discussion and follow further updates. Best, Wang -----Original Message----- From: Songbo Bu <[email protected]> Sent: Friday, June 12, 2026 3:56 AM To: [email protected]; Wang Xi <[email protected]>; [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 ALERT : This message originated outside of the Fortinet network. BE CAUTIOUS before clicking any link or opening an attachment. Hi Lun, Wang, Thanks, that direction makes sense to me. I opened a small PR against the repo: https://github.com/lihjacky/draft-on-ipsecme/pull/1 I kept it narrow. The PR does not try to change the draft's direction; it just tries to make the responder behavior easier to review and test: - strict RFC 9370 selection first; - if strict selection fails, enter only an explicitly configured extended path; - keep the extended path deterministic for the same proposal, responder capability, and policy; - evaluate duplicate selection before implicit NONE; - apply a local minimum-security policy gate before sending an accepting response; - make the selected path visible through the compatibility indication and implementation diagnostics; - make the annex profiles expose the decision-matrix fields explicitly. This is meant to address Wang's determinism point without losing the interoperability motivation in the draft. If the WG prefers Consideration 1 as the primary compatibility path and treats implicit NONE as a policy-gated fallback, I think the text will be easier to defend in Vienna. I am happy to keep iterating on the PR, split it if smaller commits are easier for you, or help turn the profiles into concrete interop test cases. Best, Songbo On Fri, 12 Jun 2026 10:25:47 +0000, "lilun (F)" <[email protected]> wrote: > 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: > > - > The responder first computes the strict RFC 9370 outcome, if one exists. > > - > If no strict outcome exists, the responder may enter an explicitly configured > extended-policy path. > > - > That extended path still needs a deterministic selection rule for the same > input, not implementation-local guesswork. > > - > The output of the extended path must be checked against a local > minimum-security policy before the responder accepts it. > > - > 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] 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] > > 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. > *** *** 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]
