> the IETF (SEC area) should produce general guidance, as a BCP, on the general topic of use of hybrid vs. pure PQ, rather than leave it to each RFC to contain more or less the same controversial text. That text would also be likely to need changing relatively soon. If there are protocol-specific issues, those of course ought be in protocol-specific RFCs.
> If that were done, then I'd see far less reason to oppose an RFC on pure ML-KEM for TLS, (or other protocols), given it'd likely have a reference to that putative SEC area BCP. [no hats] I think this is a good idea On Sat, Apr 4, 2026 at 9:43 AM Stephen Farrell <[email protected]> wrote: > > Hiya, > > On 04/04/2026 04:14, Viktor Dukhovni wrote: > > On Fri, Apr 03, 2026 at 08:13:51PM +0100, Stephen Farrell wrote: > > > >> On 03/04/2026 19:53, David Benjamin wrote: > >>> > >>> I do not think this subjective risk management question of hybrids is > >>> worthy of all of this drama and we should just accept and consider this > >>> feedback. > >> > >> For me, and some others, the question is worthy of the drama, based > >> on concerns that some issues might arise with newer algs or their > >> implementations. Seems like a matter of safety really, until one is > >> convinced of the robustness of pure PQ algs and code. You may well be, > >> but I'm not yet. > > > > You and others are of course justly entitled to be concerned about the > > potential for novel algorithms to be (un)expectedly broken, and to then > > avoid non-hybrid uses. But what I find puzzling is what one would then > > expect to be the result and benefits of non-publication? > > > > - The pure ML-KEM variants are and will be used whether or not a > > final RFC is published. > > > > - The I-D currently referenced by IANA does not reflect the concerns > > that an implementor or user should be made aware of when choosing > > to use a pure ML-KEM variant. > > > > - Ceding publication to the ISE or other SDOs seems to me to only > > dilute the standing of the IETF TLS WG as the curator of the TLS > > protocol specifications. > > > > A realist, who wants to see hybrid ML-KEM used in preference to pure > > ML-KEM would I think publish the RFC with stern warnings in the security > > considerations about why choosing hybrid is the prudent choice. > > My position is that the IETF (SEC area) should produce general guidance, > as a BCP, on the general topic of use of hybrid vs. pure PQ, rather than > leave it to each RFC to contain more or less the same controversial > text. That text would also be likely to need changing relatively soon. > If there are protocol-specific issues, those of course ought be in > protocol-specific RFCs. > > If that were done, then I'd see far less reason to oppose an RFC on > pure ML-KEM for TLS, (or other protocols), given it'd likely have a > reference to that putative SEC area BCP. > > Cheers, > S. > > > > > > Opposing publication looks pedantically counterproductive. > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
