Dear Yaroslav, Somehow, this doesn't look like a Wall of Shame, but instead an example of why this RFC should not be published.
All of these public libraries implemented solo ML-KEM without the need for this draft to be published. In other words, we don't need a published standard for implementations to proliferate and gain real world experience. Governments and compliance bodies, on the other hand, use RFCs as a normative reference, just like the Canadian Cyber Centre said they would do. To be clear, every single one of those implementations, as you said, does not enable solo ML-KEM by default. Publishing this RFC will change that. Best, Andrew > On Jul 1, 2026, at 7:46 PM, Yaroslav Rosomakho <[email protected]> wrote: > > > On Wed, Jul 1, 2026 at 2:59 PM Andrew Lee <[email protected] > <mailto:[email protected]>> wrote: >> On Jul 1, 2026, at 2:22 PM, Kevin Milner <[email protected] >> <mailto:[email protected]>> wrote: >>> several very widely deployed libraries and applications are already >>> implementing pure ML-KEM (I believe several have been cited previously in >>> the discussion of this draft, by both sides), and I suspect more will over >>> time. >> Do you happen to have a few examples or a link to this so-called wall of >> shame? > > I'm afraid you will have pretty much all mainstream TLS libraries on your > "wall of shame". > > As far as I can tell, at least the following libraries implement pure ML-KEM > support in TLS according to this specification: > - OpenSSL (ML-KEM-512/768/1024) > - BoringSSL (ML-KEM-1024) > - AWS-LC (ML-KEM-512/768/1024) > - Rustls (ML-KEM-768/1024) > - s2n-tls (ML-KEM-1024) > - Bouncy Castle (ML-KEM-512/768/1024) > - Botan (ML-KEM-512/768/1024) > - GnuTLS (ML-KEM-768/1024) > - WolfSSL (ML-KEM-512/768/1024) > > I believe that, with the exception of WolfSSL all these libraries do not > require compile-time feature flags to enable pure ML-KEM support. Worth > noting that as far as I can tell none of these libraries enable pure ML-KEM > in the default TLS configuration, they require users to make an explicit > choice to enable it. > > Hope this helps. > > -yaroslav > > > This communication (including any attachments) is intended for the sole use > of the intended recipient and may contain confidential, non-public, and/or > privileged material. Use, distribution, or reproduction of this communication > by unintended recipients is not authorized. If you received this > communication in error, please immediately notify the sender and then delete > all copies of this communication from your system.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
