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]> Sent: Tuesday, 23 June 2026 10:01 pm To: Andrew Cagney <[email protected]> Cc: Wang Guilin <[email protected]>; [email protected]; lilun (F) <[email protected]>; [email protected]; [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]
