On 7/8/2026 11:14 AM, Rob Sayre wrote:
On Wed, Jul 8, 2026 at 6:13 AM Mike Shaver <[email protected]> wrote:
(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.
Well, it was a process mistake. The SSLKEYLOGFILE document should have gone
to the ISE. It is an almost textbook case. But I think most people didn't
want to spend time arguing about log files on the internet.
https://www.rfc-editor.org/authors/rfc-independent-submissions/
And we do use this mechanism:
https://www.rfc-editor.org/info/rfc9150/
https://www.rfc-editor.org/info/rfc9189/
Those hit all of your bullet points. They don't get is this text:
"This document is a product of the Internet Engineering Task Force (IETF).
It represents the consensus of the IETF community. It has received public
review and has been approved for publication by the Internet Engineering
Steering Group (IESG)."
On the other hand, the security considerations in RFC9850 pretty clearly
state how scare the mechanism is. Applications can include protections
such as:
1. only compiling the SSL key log file if the proper flags are present
at compile time,
2. if the logging functions were compiled, only enable key logging if
the application was launched with a configuration that authorizes it,
3. if logging is compiled and authorized, only perform it if the
SSLKEYLOGFILE environment variable is present.
The equivalent protection for MLKEM would be an option to scramble the
32 bytes of output of the secure PRNG that comes with the system before
input to the ENCAPS function.
-- Christian Huitema
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
