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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
