Hi Guilin, Lun, Paul, all, Guilin's split makes sense to me. I would separate two questions:
- what an implementation should reject, diagnose, or normalize when the initiator intent is already expressible under RFC 9370; and - whether the WG wants more expression capability for cases like `(A+B) OR A OR B`. The first one seems like a good near-term target for this draft. The second one feels like a protocol-extension question and should probably not be hidden inside robustness handling for malformed proposals. For the current text, I would sketch the cases this way: - either `PQ_KEM_1` or `PQ_KEM_2`: `ADDKE1(PQ_KEM_1, PQ_KEM_2)`; - both `PQ_KEM_1` and `PQ_KEM_2`: `ADDKE1(PQ_KEM_1), ADDKE2(PQ_KEM_2)`; - `PQ_KEM_1` required, `PQ_KEM_2` optional: `ADDKE1(PQ_KEM_1), ADDKE2(PQ_KEM_2, NONE)`; - 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. That last case may be worth discussing, but it is different from saying that duplicate or unsatisfiable ADDKE lists should be accepted. For the malformed examples, I would still prefer a strict implementation-facing rule: fail configuration load on the initiator side, or normalize before sending with a clear warning; on the responder side, reject if no valid non-duplicated RFC 9370 outcome exists. The multi-proposal idea is interesting, but I would keep it clearly marked as a possible extension path because it changes the proposal language and adds selection complexity. It may be useful, but it is not just a diagnostic rule. I can help turn this into a small validation/test matrix if that would be useful for the Vienna discussion. Best, Songbo On Tue, 23 Jun 2026 03:41:34 +0000, Wang Guilin <[email protected]> wrote: > 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]> > > 收件人：[email protected] <[email protected]> > > 抄 送：lilun (F) <[email protected]>;[email protected] > <[email protected]>;[email protected] <[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: > > - proposals that are invalid and should fail at initiator configuration load; > > - proposals that can be normalized locally before sending, with a warning; > > - strict RFC 9370 responder outcomes; > > - cases where no valid RFC 9370 outcome exists and the responder rejects; > > - 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] 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]
