[Cryptography] NSA voting on TLS encryption at the IETF TLS WG

[Viktor Dukhovni]

On Thu, Jul 02, 2026 at 11:54:33AM -0700, Andrew Lee wrote:

> The IETF TLS WG is running a Working Group Last Call on
> draft-ietf-tls-mlkem-08, solo ML-KEM key exchange for TLS 1.3 without
> the classical crypto fallback. Hybrid is already standardized and
> widely deployed [1]. This draft adds the single-lock option with a
> RECOMMENDED=N flag buried in the IANA considerations, but env vars
> aren't for people.

Note that publication of the draft (informational not standards track,
and with RECOMMENDED=N in the IANA registry) is a matter of having a
stable specification for HOW to use (standalone) ML-KEM in TLS, if
that's what one chooses to do.  By way of comparison the hybrid with
X25519 is standards-track with RECOMMENDED=Y.  All that's required from
such a document is that it be a correct and clear specification, and
that its security considerations highlight any important issues.  To whit:

    https://datatracker.ietf.org/doc/html/draft-ietf-tls-mlkem-08#section-5

    ... Formal analysis has also shown that hybrid key establishment
    (e.g., [HYBRID], [ECDHE-MLKEM]) provides compositional security; the
    exchange remains secure as long as at least one of the component
    algorithms is unbroken.
    ...
    Implementers must evaluate their specific security, performance, and
    operational constraints when deciding whether to deploy standalone
    ML-KEM or a hybrid construction. The recommended column in the IANA
    TLS Supported Groups registry contains the IETF's current guidance
    on the recommended use of these algorithms for general purposes.

> The vote closes July 8.

IETF last call is not exactly a "vote", and it has now been
substantially undermined by the public campaigns to solicit
knee-jerk "votes" from non-participants.  I don't envy the
chairs the job of having to decide the outcome...
 
> Arguments [...]

Those are some of the constiderations (arguments if you prefer)
for/against selecting pure or hybrid ML-KEM, but are not arguments
for/against publication of the specification.

I am sceptical that not-publishing would ultimately deter deployment of
standalone ML-KEM (though it could introduce some delay) rather than
just further tarnish the reputation of the IETF as a forum in which one
might collaborate to develop protocol specifications.

OpenSSL supports both hybrid and standalone ML-KEM key exchange, but
only the hybrid form is enabled by default.  To use the standalone
form, both ends of the TLS connection have to apply non-default
settings.  For example, given a recent-enough Postfix, compiled
against a recent-enough OpenSSL the below invocation of
"posttls-finger" with key agreement settings  delegated to the OpenSSL
defaults and a custom ephemeral "openssl.cnf":

    $ confSection() { printf "%s = %s\n[%s]\n" "$1" "$2" "$2"; }
    $ confValue() { printf "%s = %s\n" "$1" "$2"; }
    $ grpConfig() {
        confSection "$1" init
        confSection "ssl_conf" sslmod
        confSection "system_default" ssldef
        confValue "Groups" "$2"
        }
    $ posttls-finger \
        -o tls_eecdh_auto_curves= \
        -o tls_ffdhe_auto_groups= \
        -o tls_config_name=custom \
        -o tls_config_file=<(grpConfig custom "mlkem768:*x25519:p-256") \
        -c -Lsummary dnssec-stats.ant.isi.edu

negotiates MLKEM768:

    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)

Blocking publication is IMNSHO a quixotic delaying tactic that only
serves to poison the well, but otherwise achieves nothing.

-- 
    Viktor.  🇺🇦 Слава Україні!