[IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation

[Christian Vögl <[e-mail]>]

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 <Wang.Guilin=[e-mail]>
Sent: Wednesday, 24 June 2026 03:40
To: Songbo Bu <[e-mail]>; Andrew Cagney <[e-mail]>
Cc: [e-mail]; lilun (F) <[e-mail]>; [e-mail]; [e-mail]; Wang Guilin <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, 23 June 2026 10:01 pm
To: Andrew Cagney <[e-mail]<mailto:[e-mail]>>
Cc: Wang Guilin <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; lilun (F) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 [e-mail]<mailto:[e-mail]> 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
?