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] 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]
Sent: Wednesday, 24 June 2026 03:40
To: Songbo Bu [email protected]; Andrew Cagney [email protected]
Cc: [email protected]; lilun (F) [email protected]; [email protected];
[email protected]; Wang Guilin [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]
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]
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]
