Defaults, not dogma: where OpenSSL stands on pure ML-KEM.

The IETF has been deciding whether to publish a document describing standalone ML-KEM in TLS 1.3. The argument is loud. Our position is not.

If you follow the TLS working group, you know the mailing list that normally carries a handful of messages a week has been running at over a hundred a day. The question underneath the volume is simple to state: should there be a published description of how to use ML-KEM in TLS 1.3 by itself, without a classical algorithm alongside it?

What the argument is actually about.

The disagreement is over whether that dependency is acceptable today. Sceptics hold that ML-KEM should never be used alone. Reasonable people — genuinely expert people — disagree with each other.

We support both. The default is hybrid. The configuration is yours.

We do not force a policy decision on our users, and we are not going to start now. In the library, the entire choice is one flag:

# Hybrid — the default
$ openssl s_client -connect example.com:443 -brief
Negotiated TLS1.3 group: X25519MLKEM768

# Standalone — your choice, one flag
$ openssl s_client -connect example.com:443 -brief -groups MLKEM768
Negotiated TLS1.3 group: MLKEM768

Why hybrid is the default.

History recommends humility. Across the post-quantum standardisation rounds, most candidate algorithms went in with their designers convinced they were secure, and more than half were broken along the way. That is not a criticism of anyone; it is how cryptography works.

It helps to remember what security actually is. You cannot prove an algorithm secure; you can only demonstrate it is insecure, by finding an attack. The day before an attack is published, you believe you are secure. The day after, you are not. Security is never an absolute you can guarantee — it is a trade-off. The sceptics' judgment is that, given the parameters, this particular trade-off is not yet the right one. That does not mean they know it is broken. And the absence of a published break does not make it secure.

Broken is normal. Secure is unusual. A hybrid costs little and holds if either component holds — that is what a conservative default looks like.

Why we do not go further.

Because your threat model is not ours to decide. A constrained embedded device with a compliance mandate is not a browser. A national deployment with its own cryptographic requirements is not a startup's API. Over the years we have taken criticism — some of it sharp, some of it from people we respect — for refusing to remove options that someone, somewhere, still needs. We understand that criticism. We have made the other choice deliberately: a good default for everyone, and the decision itself left with the person who owns the consequences.

The library did not wait.

The library implemented ML-KEM, hybrid and standalone, without waiting for this document. Interoperability required allocated code points, and those have existed for some time. Whatever the working group publishes, the library will do both — and the default will remain hybrid until conservatism stops being the right call.