(Apologies if this has been raised in the WGLC thread; I tried to catch up there, but there is...a lot.)
I'm curious how the list feels about similarities between the decision to standardize SSLKEYLOGFILE and the choice ahead of the IETF regarding standalone ML-KEM. As I recall and understand the consensus, the decision was taken to specify SSLKEYLOGFILE (albeit as informational) was taken - in spite of the fact that SSLKEYLOGFILE can be used in ways that harm confidentiality - because people are going to implement it anyway - so those systems might as well be interoperable - and the RFC can provide guidance on how to avoid some security risks At the time there was concern that publishing such a specification would be taken as IETF endorsement of the practice of adding silent facilities that compromise key security. The consensus that emerged, though, was that such a possibility was outweighed by the utility of having interoperable implementations. Is the decision about ML-KEM not of a very similar shape? Standalone ML-KEM is *going* to happen, as evidenced by even just the statements of intent made in the WGLC thread. The IETF can help it happen interoperably with some guidance, or not. It seems like consensus has been somewhat more difficult to determine for standalone ML-KEM than it was for SSLKEYLOGFILE, and I'm interested to hear from people who were for SSLKEYLOGFILE but who are against standalone ML-KEM: how do these situations differ? What underlying principles are guiding your position? Thanks, Mike
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
