On Mon, Mar 23, 2026 at 04:30:45PM +1100, Viktor Dukhovni wrote:
> Given the extant IANA code points, and that support for non-hybrid
> ML-KEM is already present (though typically either or both not
> preferred, or enabled by default) in multiple TLS libraries, I see no
> rational motivation to oppose publication "in any form". Surely, with
> appropriate caveats there's a way to get this specification published
> as an informational(!) RFC.
>
> Blocking its publication changes little in practice, but creates some
> confusion about whether the specification is still subject to change,
> and may leave an impression that the IETF is out of touch. :-(
FWIW, by way of a mainstream reality check, the "gmail.com"
best-preference MX hosts accept "mlkem1024" by default (OpenSSL 3.5 and
later need to be explicitly coaxed to offer it):
$ openssl s_client -brief -starttls smtp -CAfile /etc/pki/tls/cert.pem \
-connect gmail-smtp-in.l.google.com:25 -groups mlkem1024
Connecting to 142.251.12.27
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Requested Signature Algorithms:
ecdsa_secp256r1_sha256:rsa_pss_rsae_sha256:rsa_pkcs1_sha256:ecdsa_secp384r1_sha384:rsa_pss_rsae_sha384:rsa_pkcs1_sha384:rsa_pss_rsae_sha512:rsa_pkcs1_sha512:rsa_pkcs1_sha1
Peer certificate: CN=mx.google.com
Hash used: SHA256
Signature type: ecdsa_secp256r1_sha256
Verification: OK
Negotiated TLS1.3 group: MLKEM1024
250 SMTPUTF8
quit
221 2.0.0 closing connection 41be03b00d2f7-c745e5d046csi13003379a12.253 -
gsmtp
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
