On Wed, Jul 01, 2026 at 08:03:29PM -0700, Andrew Lee wrote:
> To be clear, every single one of those implementations, as you said,
> does not enable solo ML-KEM by default. Publishing this RFC will
> change that.
I don't expect publication of the RFC to have much bearing on the
default key exchange group list in OpenSSL. Even if pure ML-KEM were
added to the list, so long as CrQCs capable of routinely breaking ECDHE
are still in the indefinite future, are unknown to exist, or are very
scarce, the hybrid groups will be listed first and will be negotiated
when mutually supported. In closed ecosystems, Users who control both
ends of a TLS connection can opt into pure ML-KEM if that's what they
prefer.
A couple of SMTP servers I manage accept pure ML-KEM as a fallback
from the default hybrid options:
$ tlsGroups() {
printf "$1=c\n[c]\n"
printf "ssl_conf=s\n[s]\n"
printf "system_default=d\n[d]\n"
printf "Groups=$2\n"
}
$ /opt/postfix/sbin/posttls-finger -o tls_config_name=conf \
-o tls_config_file=<(tlsGroups conf mlkem768) \
-c -Lsummary $(uname -n)
posttls-finger: Verified TLS connection established
to dnssec-stats.ant.isi.edu[2001:1878:401::8009:1dfe]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange MLKEM768 server-signature ML-DSA-44 (raw public key)
The only connections of this sort I've observed are my own tests.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
