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 [email protected]<mailto:[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]
