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]
