Tommy Jensen wrote: >As it stands, I cannot in good faith agree this document is ready for >publication when the only other RFC (9963) to define Recommended=N values in >this registry not published through ISE (and therefore lacks the "IETF doesn't >endorse this" language) went to great lengths to explain why it is =N, but >this document says absolutely nothing about it. That creates a very obvious >difference in the documents with =N entries, where all but one explicitly tell >the reader it isn't endorsed or it normatively must/should not be used in the >default case.
I don't think an ISE document should set any precedent for working group documents. This is also not the first working group document to use RECOMMENDED = N. draft-ietf-tls-ecdhe-mlkem, the first working group document to be published after RFC 9847, does the same. RFC 9847 significantly revised the definitions of Y and N and introduced RECOMMENDED = D, so registrations made before RFC 9847 have limited relevance. People may have different views, but my view is that RECOMMENDED = N does not require any explanation, whereas RECOMMENDED = Y and RECOMMENDED = D do. I see RECOMMENDED = N as the new default. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://datatracker.ietf.org/doc/html/rfc9847 Cheers, John Preuß Mattsson From: Tommy Jensen <[email protected]> Date: Thursday, 2 July 2026 at 16:04 To: Salz, Rich <[email protected]>; Bas Westerbaan <[email protected]> Cc: The IESG <[email protected]>; draft-ietf-tls-mldsa <[email protected]>; tls-chairs <[email protected]>; tls <[email protected]> Subject: [TLS] Re: Tommy Jensen's Discuss on draft-ietf-tls-mldsa-04: (with DISCUSS and COMMENT) Thank you for the list reference. I agree with Eric that a comparison is unnecessary. I'm not interested in seeing this document stack ranking itself against other documents. What I am asking for is an explanation as to why it is =N, which can be done without making any comparisons. For those following along on email, the rejected text was a simple reference to Section 9.1 of draft-ietf-lamps-pq-composite-sigs, saying it "considers when a PQ/T could be preferred": https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-sigs-19#section-9.1 My concern unfortunately is not mitigated by the change being contentious. As it stands, I cannot in good faith agree this document is ready for publication when the only other RFC (9963) to define Recommended=N values in this registry not published through ISE (and therefore lacks the "IETF doesn't endorse this" language) went to great lengths to explain why it is =N, but this document says absolutely nothing about it. That creates a very obvious difference in the documents with =N entries, where all but one explicitly tell the reader it isn't endorsed or it normatively must/should not be used in the default case. This could be as simple as explaining exactly what you just stated: this Informational standard was adopted by the WG because it saw value in standardizing the mechanism, but did not have consensus to set Recommended=Y because there was disagreement at publication time that pure PQ algorithms have sufficient experience in deployment to be recommended. Note that there is no need to then proceed to explain "because <pure PQ versus hybrid debate>", though it circles back to the concern other ADs have about maybe Experimental being a better fit for this. On Jul 2, 2026 at 05:54, Bas Westerbaan <[email protected]<mailto:[email protected]>> wrote: Adding some words on composites has been proposed, and got pushback, eg. https://mailarchive.ietf.org/arch/msg/tls/7TDHk9yQQ_LvXFwMG7dJmsC9YEs/ On Thu, Jul 2, 2026 at 2:50 PM Salz, Rich <[email protected]<mailto:[email protected]>> wrote: There is not WG consensus to recommend pure-PQ algorithms at this time. I doubt further clarification is needed, and adding any words runs the risk of restarting the flame wars that have enveloped the WG on this issue.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
