The division comes from if there is a need to expand the expression capability of RFC 9370, I think.
Agree with Pual on that the two scenarios given in Section 4 are odd or not so convincing. They just tell that the initiators prepares its ADDKE proposal in that way, which violats the requirements specified in RFC 9370, but not what the intention of the initiator is, and if there are possible right way to prepare its ADDKE proposal by following RFC 9370. For Scenario 1 or 2, if the intention of the initiator is to run PQ_KEM_1 or PQ_KEM_2 with the responder, it SHOULD prepare its proposal as ADDKE1(PQ_KEM_1, PQ_KEM_2). If the intention of the initiator is to run PQ_KEM_1 and PQ_KEM_2 with the responder, it SHOULD prepare its proposal as ADDKE1(PQ_KEM_1), ADDKE2(PQ_KEM_2). If the intention of the initiator is to run PQ_KEM_1 and PQ_KEM_2 as the firs choice, but also acceptable for just running PQ_KEM_1, it SHOULD prepare its proposal as ADDKE1(PQ_KEM_1), ADDKE2(PQ_KEM_2, NONE). Namly, here PQ_KEM_1 is a mandatory requirement for the initiator, but PQ_KEM_2 is optional. However, according to RFC 9370, it seems no way for the initiator to express the following as its intention. Case 1: Both of them or one of them, i.e, (PQ_KEM_1 AND PQ_KEM_2) OR (PQ_KEM_1) OR (PQ_KEM_2). So, the real question probably is if there is a need to expand the expression capability of RFC 9370 to including the cases like the above. --------- If such a need is good to have, we acutually can choose another way to express all possible cases by laying up ADDKEs. Namely, we may expend ADDKEs to sevearl Proposals as RFC 7296 did for KE algorithms. As an example, for Case 1 above, the initiator can prepare its proposals as the following: Proposal 1: ADDKE1(PQ_KEM_1), ADDKE2(PQ_KEM_2). Proposal 2: ADDKE1(PQ_KEM_1, PQ_KEM_2). Then, the responder is required to select one of proposals from the initiator by following RFC 9370. Dupicated algorithms are allowed in different proposals, and special cases like Case 1 can be covered. But then, we will have multiple of proposals and introduce some complexity. Just got this idea. I think it works. --------- By the way, we have a new draft called multi-authentication, that mimics the multiple KE in RFC 9370 but for authentication. It is realised via expanding the authentication announcement specified in RFC 9593. https://datatracker.ietf.org/doc/draft-wang-ipsecme-multi-auth-ikev2-pq/ Your comments/reviews are welcome. Cheers, Guilin 发件人：Songbo Bu <[email protected]<mailto:[email protected]>> 收件人：[email protected] <[email protected]<mailto:[email protected]>> 抄 送：lilun (F) <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>> 时 间：2026-06-23 09:23:25 主 题：[IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation Hi Paul, Lun, Wang, all, Paul’s point makes sense to me. If the examples are unsatisfiable from the initiator side, then the draft should not read as relaxing RFC 9370 or accepting duplicate KEM contributions just to tolerate bad configuration. A narrower way to keep the useful part may be to reframe the work around explicit rejection/diagnostics and optional local normalization before proposals go on the wire. For example, an implementation-facing matrix could separate: 1. proposals that are invalid and should fail at initiator configuration load; 2. proposals that can be normalized locally before sending, with a warning; 3. strict RFC 9370 responder outcomes; 4. cases where no valid RFC 9370 outcome exists and the responder rejects; 5. any explicitly configured local compatibility behavior, if the WG still wants to discuss it. That would preserve the main security property: the wire outcome still has to be a valid, non-duplicated RFC 9370 selection, except for the existing NONE rules. So I agree the draft should not justify duplicate selection as a robustness feature. The useful deliverable may instead be a short “how to reject or normalize ADDKE proposal mistakes” document plus test cases. Best, Songbo On Mon, 22 Jun 2026 13:17:17 -0400 (EDT), Paul Wouters [email protected]<mailto:[email protected]> wrote: On Mon, 22 Jun 2026, Songbo Bu wrote: Subject: [IPsec] Re: New I-D: draft-li-ipsecme-extensions-for-robust-negotiation I am late reading this draft, my apologies. I find the examples in Section 4 odd. To me, those are both valid cases to fail the IKE SA as initiator and responder do not have matching requirements. Scenario 1: The initiator sends a proposal where ADDKE1, ADDKE2, and ADDKE3 each contain the identical list of algorithms: PQ_KEM_1 and PQ_KEM_2. Clearly this proposal should fail to load on the initiator, as it can never be satisfied, unless ADDKE3 is always just NONE. And having an empty “must be NONE” proposal makes no sense. Scenario 2: The initiator sends a proposal where ADDKE1 contains PQ_KEM_1 and PQ_KEM_2, while ADDKE2 contains only PQ_KEM_2. Again, this proposal should fail to load on the initiator, as it can never be satisfied. Or it should remove PQ_KEM_2 from ADDKE1 while loading and log a warning. But this requires more complicated code. Not seeing an actual problem with RFC 9370, I am not convinced we need this robustness draft. I am also not convinced that we need to allow things like duplicate algorithms to allow for misconfigurations. Perhaps there is a use for a document on how and when to reject ADDKE proposals, but this document does not do that. Paul
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
