Hi Paul, Songbo, and all, Thanks for the feedback. Paul’s point on keeping the protocol clean is well taken. We should not encourage misconfigurations on the wire. The problem does not lie in the problem of RFC itself, but rather in the issues caused by certain implementations due to the understanding and how to mitigate them. There could be a way that shifting the focus of this draft toward a guidance document on how to validate, normalize in responder’s local processing, or reject problematic ADDKE proposals makes practical sense for the industry. I can think about it and discuss before and during the Vienna meeting. I would say that, from an vendor best practice, the priority is to safely and timely complete the post-quantum migration to mitigate CRQC threats. I mean at the end of the day, many developers and network administrators implementing these hybrid KEM features lack deep RFC experience. Configuration mistakes, template overlapping, and parsing errors will happen during early deployments. If implementations handle these mistakes inconsistently or fail, it will prolong migration timelines and introduce interoperability bugs. Mitigating these practical operational risks is always valuable for the ecosystem. Best, Lun Li
------------------------------------ Sender: Songbo Bu <[email protected]> Sent: June 23, 2026, 9:22 To: [email protected] Cc: lilun (F) <[email protected]>; [email protected]; [email protected] Subject: Re: [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]
