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

I have just stumbled upon Dr. Roberto Avanzi's post on LinkedIn.

Dr. Avanzi, who is one of the designers of ML-KEM, writes (in an answer to
Dr. Bernstein tweet that was shared by Prof. Bill Buchanan), and I quote:
"In my opinion the issue is not implementation errors, they can be avoided
with the right discipline. But, as a codesigner of ML-KEM myself I would
not trust using it exclusively: what if it gets broken mathematically and
in the classical computational model (I.e. non-quantum)? Hybrid is better,
and the additional time used by ECC is not significant."

I can offer a screenshot of the reply to support its accuracy (as linkedin
does not offer a simple mechanism for linking to a specific post and/or
reply that I am aware of).

I know that this point has been raised before, but the fact that a
co-designer of ML-KEM says so publicly, may carry some weight for some
people (rather than just cryptographers wanna-bes and trolls suggesting
this exact same claim).

On Wed, Jul 8, 2026 at 11:54 PM Ilari Liusvaara <[email protected]>
wrote:

> On Wed, Jun 24, 2026 at 08:00:07AM -0700, Joseph Salowey via Datatracker
> wrote:
> > This message initiates a new Working Group Last Call for
> > draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key
> > establishment for TLS 1.3.
>
> I support publishing this.
>
>
> I do not think hybrids are a major improvment. However, because hybrid
> key exchange in TLS 1.3 is extraordinarily cheap, I think ECDH+PQ
> hybrids should be used unless following security profile standard
> specifying otherwise, CRQCs having rendered traditional cryptography
> moot, or system constraints somehow make hybrids impractical.
>
> And given how close my position is, it takes very little to tilt
> the scale the other way. Furthermore, CRQC appearing would instantly
> tilt the scale the other way. So I think wanting to use stand-alone
> ML-KEM is completely understandable.
>
> (My position on hybrid signatures is very different due to much
> bigger costs, and is not even close to the tipping point.)
>
>
> ML-KEM security, mathematical level:
> ------------------------------------
> Post-quantum cryptography is not a type of cryptography, it is attribute
> of cryptography. The candidates to NISTPQC were very diverse, and as
> different types of cryptography tend to have different attacks (with
> some common ones), one can not use failures of other types (e.g., SIKE)
> or the general failure rate (there was plenty of "snake oil") as
> evidence against Kyber/ML-KEM.
>
> For the submissions based on lattices, the issues seemed to be mostly
> bad parameter choices and some other details. Which is also to be
> expected, and does not reflect badly on Kyber/ML-KEM.
>
> The MLWE problem underlying Kyber/ML-KEM seems to be the best problem
> currently available. Decent message sizes combined with loads of
> analysis. LWE would be even better from analysis standpoint, but the
> message sizes are pretty painful.
>
> Cryptography based on lattices is not new. NTRU is from 1996, and LWE
> (which is commonly regarded as better than NTRU) is from 2005. In
> addition Kyber/ML-KEM also has extensive analysis as part of NISTPQC,
> probably exceeding any other candidate KEM. Lattices are also a
> generally useful topic, and as such have attracted a lot of mathematical
> research for a long time.
>
> And looking at known attacks, it is clear that anything besides
> breaking ML-KEM-512 with extreme effort (not going to be worth it)
> requires a fundamentally new attack.
>
> Comparing to ECC, ECC has also seem a lot of analysis since it was
> introduced in 1985, and is also based on generally useful topic that
> has attracted a lot of mathematical research over a long time.
> Breaking the cases that have not already been broken also requires
> either quantum computer or a fundamentally new attack.
>
>
> ML-KEM security, implementation level:
> --------------------------------------
> Unlike mathematical level, which needs to stand the test of time, the
> implementations do not. A well-done implementation is good right off
> the gate. A badly-done implementation will remain bad even after
> plenty of time.
>
> Implementation quality is not gated by algorithm understanding or CS
> theory. As consequence, implementations do not really improve over
> time. More implementations get written, some of those are good. And the
> bad implementations tend to patch the worst stuff (but likely never
> become good).
>
> Fortunately, implementation quality of ML-KEM in TLS is not very
> important: ML-KEM is not prone to to implementation flaws so bad that
> all security is destroyed, hybrid or not. The remaining flaws tend to
> be either strongly mitigated by not reusing keys (required by
> RFC8446bis) or destroy interop. Hybrids are practically useless here.
>
> Comparing to ECC, ECC also has history of all kinds of bad
> implementations. And some forms of ECC (thankfully not supported in
> TLS 1.3) are not resistant to flaws that instantly destroy all
> security.
>
>
>
>
> -Ilari
>
> _______________________________________________
> 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]