[TLS] Re: SSLKEYLOGFILE vs pure-ML-KEM

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]