Hi, I think that the draft should provide clarifications and examples of what initiator’s proposals will cause troubles. For example, the proposal from the draft: ADDKE1(PQ_KEM_1, PQ_KEM_2), ADDKE2(PQ_KEM_1, PQ_KEM_2), ADDKE3(PQ_KEM_1, PQ_KEM_2) is invalid, since it requires using 3 additional key exchanges with only 2 allowed KEMs. With the current rules from RFC 9370 this conditions cannot be met, thus the initiator proposing this is broken. On the other hand, just populating several ADDKE transforms with the same list of KEs is permitted, if it is possible to choose different KEs for each ADDKE. For example, in the initiator proposes ADDKE1(PQ_KEM_1, PQ_KEM_2), ADDKE2(PQ_KEM_1, PQ_KEM_2) it means, that it insists on applying both PQ_KEM_1 and PQ_KEM_2 in any order, so that both ADDKE1(PQ_KEM_1), ADDKE2(PQ_KEM_2) and ADDKE1(PQ_KEM_2), ADDKE2(PQ_KEM_1) are valid combinations for selection. If the order of applying KEs is important for the initiator, then it would propose (assuming PQ_KEM_1 first and then PQ_KEM_2) ADDKE1(PQ_KEM_1), ADDKE2(PQ_KEM_2) And so on. So, I think that the draft should just clarify all these nuances, making advises for implementers and operators, but should not touch the current selection logic from RFC 9370. And I think that in this case the draft should be Informational. Regards, Valery. Hi all, Based on our discussion during the IPsecME session and my chat with Valery, I think a practical direction for this contribution would be to provide clear instructions and operational guidance for ADDKE selection based on existing RFC, rather than modifying or extending them. I believe a guidance for implementation will still be very valuable for developers and implementers in the ecosystem, since it can reduce the developer’s costs on understanding the multiple selection logic. Future revisions of the draft will focus on this direction, and I strongly welcome collaboration from other vendors and experts. Looking forward to further discussions. Best regards, Lun Li 发件人: lilun (F) <[email protected]> 发送时间: 2026年6月25日 15:15 收件人: Christian Vögl <[email protected]>; Wang Guilin <[email protected]>; [email protected] 主题: [IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation Hi Christian, Guilin, and all, I think Christian's reading is correct. RFC 9370 does not restrict the initiator from proposing the same algorithms for different ADDKE payloads; it only restricts the responder from selecting duplicate algorithms. Though the text in the RFC has some ambiguity, which could also lead to different interpretations. It seems we have much discussion focused on whether the initiator shall/shall not make a proposal like this/that according to RFC. My observation is that some standards could impose strict negotiation rules, but at the end of the day, if experts may misinterpret the RFC, developers implementing these features will inevitably make similar errors. I think it is agreed that the goal is to ensure that devices supporting multiple KEs can successfully negotiate a post-quantum secure algorithm list, rather than failing due to configuration overlapping or developers' misunderstanding of the RFC. As more KEM algorithms are introduced in the future, these configuration complexities will only increase. It is from this perspective that I feel addressing these edge cases brings practical value to the ecosystem. Best Regards, Lun Li 发件人: Christian Vögl <[email protected]> 发送时间: 2026年6月24日 15:54 收件人: [email protected] 主题: [IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation Hi, I don’t think there is a problem with that proposal. In RFC9370 I could only find that requirement for the responder’s choice. Additionally section 2.2.1 has an example exchange with ADDKE2=PQ_KEM1, PQ_KEM_2 ADDKE3= PQ_KEM1, PQ_KEM_2 Christian From: Wang Guilin <[email protected] <mailto:[email protected]> > Sent: Wednesday, 24 June 2026 03:40 To: Songbo Bu <[email protected] <mailto:[email protected]> >; Andrew Cagney <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> ; lilun (F) <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> ; Wang Guilin <[email protected] <mailto:[email protected]> > Subject: [IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation Got a little confused. What I know is, according to RFC 9370, the initiator is not allowed to prepare the following ADDKEs, as beside NONE, any other KEM cannot be duplicated in two or multiple ADDKEs. addke1=kem1,kem2 addke2=kem1,kem2,none Guilin From: Songbo Bu <[email protected] <mailto:[email protected]> > Sent: Tuesday, 23 June 2026 10:01 pm To: Andrew Cagney <[email protected] <mailto:[email protected]> > Cc: Wang Guilin <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; lilun (F) <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> Subject: Re: [IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation Hi Andrew, Yes, I think you are right. I was reading that case too narrowly. With: ADDKE1 = { PQ_KEM_1, PQ_KEM_2 } ADDKE2 = { PQ_KEM_1, PQ_KEM_2, NONE } the responder can express the outcomes I had in mind, assuming the normal RFC 9370 rule that the selected non-NONE algorithms are not duplicated: * both: select PQ_KEM_1 in one ADDKE slot and PQ_KEM_2 in the other; * only PQ_KEM_1: select PQ_KEM_1 and NONE; * only PQ_KEM_2: select PQ_KEM_2 and NONE. So I would retract my “not directly expressible” phrasing for that row. The remaining implementation-facing point still seems useful: if the initiator’s intent is “one mandatory from this set, plus at most one optional additional method from the same set”, it should encode that with an explicit NONE in the optional ADDKE slot, not by sending repeated mandatory ADDKE lists and expecting the responder to repair them. A responder should still reject outcomes that require duplicated non-NONE algorithms or an implicit NONE that was not proposed. Best, Songbo On Tue, 23 Jun 2026 09:40:09 -0400, Andrew Cagney <mailto:[email protected]> [email protected] wrote: * both-or-one, meaning (PQ_KEM_1 AND PQ_KEM_2) OR PQ_KEM_1 OR PQ_KEM_2: not directly expressible as one RFC 9370 proposal, as far as I can tell. addke1=kem1,kem2 addke2=kem1,kem2,none ?
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
