Well, you are right - RFC 9189 should not have been standardized. It is based on a cryptographic primitive, namely Kuzneychik, designed by TC26 of the FSB (KGB's new name) which was shown to have structure in the S-boxes [0,1,2], despite a claim by the designers that the S-boxes were random. The claim about the S-boxes being generated at random was discussed in ISO/IEC JTC1 SC27 WG2 for a very very long time (including the Berlin 2017 meeting and the Tel Aviv 2018 one, as well as god knows how many comments). In ISO, the discussion ended in Kuznyechik not being standardized back then, but not by the removal of the existing Streebog hash function that uses the same problematic S-box. During the same time, another set of cryptographic primitives designed by a different three letters agency was also not accepted by ISO, as again, this agency thought it was sufficient to claim that the cipher is secure because they are the NSA and why would they want to have a weak encryption standard to begin with. Suggesting that they had a funding for making weak standards and/or pointing out to weakened standards that they pushed for, failed to trigger the understanding that the claim that they can be trusted is not a sufficient argument.
I would guess that once there is an RFC that says this is the Kuznyechik block cipher (namely, RFC 7801), it is a bit harder to say to people - hey, this cipher, which appears in an RFC, cannot be used in TLS, because we found problems in the cipher. This is why whatever was in ISO _before_ the issues were discovered, was left and not removed, whereas the new stuff was not accepted. The moral of the story I take from this experience: 1. Don't add stuff that "looks" OK now, because you will get stuck with it in the future. 2. Standardization of ideas supported by agencies responsible both for protecting the infrastructure of a given country and attacking the infrastructure of other countries should be taken with a grain of salt (or a 128-bit salt to ensure security). [0] Alex Biryukov, Léo Perrin & Aleksei Udovenko, "Reverse-Engineering the S-Box of Streebog, Kuznyechik and STRIBOBr1", EUROCRYPT 2016, https://link.springer.com/chapter/10.1007/978-3-662-49890-3_15 [1] Leo Perrin & Aleksei Udovenko "Exponential S-Boxes: a Link Between the S-Boxes of BelT and Kuznyechik/Streebog", ToSC 2016, https://tosc.iacr.org/index.php/ToSC/article/view/567/509 [2] Leo Perrin, " Partitions in the S-Box of Streebog and Kuznyechik", ToSC 2019, https://tosc.iacr.org/index.php/ToSC/article/view/7405 On Thu, Jul 2, 2026 at 6:54 PM Markku-Juhani O. Saarinen < [email protected]> wrote: > Hi All, > > > I'd like to see a specification for "pure" ML-KEM for TLS published as an > informational RFC. This is mainly because of low-end hardware use cases -- > but first, some notes: > > This is an informational RFC -- there is no obligation to implement or use > it, and I don't see draft-ietf-tls-mlkem-08 promoting it for general use > (the quoted IANA "Recommended: N" column seemigly implies the opposite). To > me, publishing an Informational RFC primarily means that there is a freely > available and stable specification that enables interoperable > implementations when needed. I think it is useful that a stable > specification for pure ML-KEM exists long before live attacks against PQC > start to occur, and more organizations will want to drop hybrid. > > As a sidenote, we already have the Chinese TLS 1.3 Cipher Suites (RFC > 8998), Russian TLS 1.2 Cipher Suites (RFC 9189), etc., and a lot more > obscure and weird ones too. Those didn't generate nearly as much discussion > and passion as this seems to have. > > Why would I personally need a spec for pure ML-KEM it right now? While > hybrid seems "easy" from a software viewpoint, ECDH and ML-KEM don't share > many hardware resources; ECDH is "big integer" arithmetic, while ML-KEM is > ring arithmetic; ML-KEM and ML-DSA use the SHA3 family, while legacy crypto > uses SHA2, etc. With hybrid, one is significantly increasing the size and > complexity of a hardware implementation with little verifiable security > advantage. > > > As a cryptographer and security engineer, I don't have much sentimental > attachment to Elliptic Curve Cryptography. Individuals and organizations > can certainly use hybrids, but I just don't see directly identifiable > security value in it for the use cases I have. So: I personally don't want > to have ECDH baggage on my chip simply due to some "belts and suspenders" > argument. > > > ps. On the same vein -- It would be absolutely fantastic if we could get > rid of HKDF as it is the one thing in TLS 1.3 forcing masked SHA2 on my > chip. As a symmetric cryptography design, HKDF is about as inelegant as > possible, and currently one of the hardest things to mask & secure in > hardware. Arguably better SHA3-based KDFs have existed for a long time, and > I'd like to use my masked Keccak module for KDF. But that's perhaps for > later. > > > Cheers, > -markku > > Dr. Markku-Juhani O. Saarinen <[email protected]> > _______________________________________________ > 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]
