I meant -- live attacks against non-PQC. Cheers, -markku
Dr. Markku-Juhani O. Saarinen <[email protected]> On Thu, Jul 2, 2026 at 6:53 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]
