Hi Christian, If one does not trust the RBG they use, they should add that hash to all outputs of the RBG to protect their system and in this case the hash function is considered a part of a new RBG which has this outer hash on top of the RBG they don't trust.
Protecting the KEM alone and let the rest of the system broken would not be the best I think. Or, don't use that RBG, use the one you trust or develop your own RBG. Regards, Quynh. > -----Original Message----- > From: Christian Huitema <[email protected]> > Sent: Wednesday, July 8, 2026 2:43 PM > To: Rob Sayre <[email protected]>; Mike Shaver <[email protected]> > Cc: TLS List <[email protected]> > Subject: [EXTERNAL] [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://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc-editor.org%2Fauthors%2Frfc-independent- > submissions%2F&data=05%7C02 > > > %7Cquynh.dang%40nist.gov%7C9b631e4c2b9141a88a9608dedd21049b% > 7C2ab5d82f > > > d8fa4797a93e054655c61dec%7C0%7C0%7C639191331074762061%7CUn > known%7CTWFp > > > bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4 > zMiIsIk > > > FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z86jqLRFeOLo > kLEcFHaz > > T5MuUTZ%2FOL4Fhj2uY67TEdc%3D&reserved=0 > > > > And we do use this mechanism: > > > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc- > editor.org%2Finfo%2Frfc9150%2F&data=05%7C02%7Cquynh.dang%40nist.g > o > > > v%7C9b631e4c2b9141a88a9608dedd21049b%7C2ab5d82fd8fa4797a93e0 > 54655c61de > > > c%7C0%7C0%7C639191331074797121%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGk > > > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyf > > > Q%3D%3D%7C0%7C%7C%7C&sdata=anaPoo9ZQzElKGh87NznhwL5z1Ki%2B > IMe6Ijmi%2Bg > > 7gZI%3D&reserved=0 > > > https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > rfc- > editor.org%2Finfo%2Frfc9189%2F&data=05%7C02%7Cquynh.dang%40nist.g > o > > > v%7C9b631e4c2b9141a88a9608dedd21049b%7C2ab5d82fd8fa4797a93e0 > 54655c61de > > > c%7C0%7C0%7C639191331074819422%7CUnknown%7CTWFpbGZsb3d8e > yJFbXB0eU1hcGk > > > iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyf > > > Q%3D%3D%7C0%7C%7C%7C&sdata=TU%2FqRIaVTEi0jbOC9DRwKIf1xX9%2 > FXSc2Vv4DyVv > > PttM%3D&reserved=0 > > > > 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] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
