Thanks for the message, Songbo. Yesterday, I also read several related parts ib RFC 9370. It indedd means:
"overlapping candidate lists are valid input; duplicate selected non-NONE ADDKE methods are not valid output; " as you summarzied. So, the expressability seems no problem at all. Guilin 发件人：Songbo Bu <[email protected]<mailto:[email protected]>> 收件人：[email protected] <[email protected]<mailto:[email protected]>> 时 间：2026-07-04 03:43:59 主 题：[IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation Hi Christian, Guilin, Andrew, all, Thanks, Christian. I checked RFC 9370 again and I agree with your reading. The no-duplicate requirement is on the responder’s choice, not on the initiator’s candidate lists. The example in Section 2.2.1 also uses overlapping candidates across ADDKE2/ADDKE3, which makes that fairly clear. So I would refine my earlier note as follows: ADDKE1={PQ_KEM_1,PQ_KEM_2}, ADDKE2={PQ_KEM_1,PQ_KEM_2,NONE} is a valid way to express “one mandatory from this set, plus optionally one more from the same set”, assuming the responder selects no duplicate non-NONE methods. The implementation boundary is on the selected result and error handling, not on the proposal merely containing overlapping candidate sets. For the robustness draft, I think that leaves a useful but narrower point: * overlapping candidate lists are valid input; * duplicate selected non-NONE ADDKE methods are not valid output; * explicit NONE and omitted ADDKE transform slots should be handled exactly as RFC 9370 specifies, not with extra local interpretation; * diagnostics/test cases should distinguish “overlap in proposal” from “duplicate selected algorithms”. Best, Songbo On Wed, 24 Jun 2026 07:53:45 +0000, “Christian Vögl” [email protected]<mailto:[email protected]> wrote: 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]
