[ I updated the Subject for better archival visibility ]
On Fri, 10 Oct 2025, Rob Sayre wrote:
That does not seem to be a good reason. I'll join DJB's appeal, then. There is no reason for this to be a WG document. Just register the codepoints. Paul: My appeal comes with no strings attached. I appeal the WG adoption of "draft-connolly-tls-mlkem-key-agreement", as a WG document. It contradicts the reasoning in "Hybrid key exchange in TLS 1.3", which is already in the RFC Editor queue.
As per RFC 2026 Section 6.5.4 https://datatracker.ietf.org/doc/html/rfc2026#section-6.5.4 All appeals must include a detailed and specific description of the facts of the dispute. All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged. Your appeal fails on both grounds. I must therefore deny your appeal. The WGLC consesus call was issued on April 15 2025. https://mailarchive.ietf.org/arch/msg/tls/_AWy51BSgX1ipv0hfnAzLrDrTYI/ This means you are four months too late to file an appeal. Appeals fired off in the spur of a heated discussion in the form of a single sentence are unlikely to comply with the above text stating "detailed and specific description of the facts of the disput" or with the IESG guidance on conflict resolution and appeals: https://datatracker.ietf.org/doc/statement-iesg-statement-on-the-conflict-resolution-and-appeals-processes/ I want to also note that the WG may still discuss any aspect of this draft and at any time during the document lifecycle it may decide to abandon or unadopt the work - for example if new arguments not heard before surface that were not taken into consideration during the adoption call by the WG. You may also state your objections again during the WG Last Call, and the IETF Last Call. Paul Wouters Security Area Director
thanks, Rob On Fri, Oct 10, 2025 at 1:18 PM Deirdre Connolly <[email protected]> wrote: If you are fine with ML-KEM, you should be able to use it on its own. That's it. On Fri, Oct 10, 2025, 4:17 PM Rob Sayre <[email protected]> wrote: Hi, Alright, but that's the issue. I hope we can stick to that point. "migrating beyond hybrids and for users that need to be fully post-quantum." Where does the need to be solely PQ arise? Is it weaker in some way to use a hybrid? thanks, Rob On Fri, Oct 10, 2025 at 1:10 PM Deirdre Connolly <[email protected]> wrote: https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-04.html#name-motivation https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-02.html#name-the-commercial-national-sec On Fri, Oct 10, 2025 at 4:07 PM Rob Sayre <[email protected]> wrote: Hi, That does not answer my question: why? The hybrid draft has a rationale: https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-16#name-motivation-for-use-of-hybri thanks, Rob On Fri, Oct 10, 2025 at 1:02 PM Deirdre Connolly <[email protected]> wrote: The drafts and the profile currently do not make Recommendations or MTI's, they make the options available; ekr has now raised promoting one hybrid option as Recommended = Y. Not everyone can or should use the same options, we have a diversity of curves for example On Fri, Oct 10, 2025 at 3:56 PM Rob Sayre <[email protected]> wrote: On Fri, Oct 10, 2025 at 12:33 PM Deirdre Connolly <[email protected]> wrote: CNSA 2.0 does not support hybrids in general, and their TLS profile only supports ML-KEM-1024: https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile/ Hi, But why is that? See this thread from the IETF general list: https://mailarchive.ietf.org/arch/msg/ietf/Xei2iDOk6zorD4oFnLoJ5mAdkdQ/ As pointed out in that thread, all of these drafts seem to conflict with the rationale in draft-ietf-tls-hybrid-design. thanks, Rob
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
