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] 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]
