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]
