[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

["Markku-Juhani O. Saarinen" <[e-mail]>]

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 <[e-mail]>