[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

[John Mattsson <[e-mail]>]

Hi Yaroslav,

As noted in the quote from Viktor Dukhovni below, OpenSSL 3.5 includes TLS code points for ML-DSA but not for SLH-DSA. One likely reason is that the authors of the SLH-DSA draft did not register any code points in the IANA registry, whereas the ML-DSA draft authors did.

I previously mentioned that Ericsson planned to support SLH-DSA in TLS for use in 5G deployments. However, with OpenSSL 3.5 LTS not providing TLS code point support for SLH-DSA, this may be significantly delayed. At this point, standalone ML-DSA appears to be the only realistic option for TLS 1.3, DTLS 1.3, QUIC, and EAP-TLS 1.3. Support in major TLS libraries remains essential for any practical deployment, and migration of PKI and trust-anchors need to start today to have any realistic chance to meet 2030-2035 government deadlines for disabling RSA in ECDSA in deployments.

Cheers,
John

From: Yaroslav Rosomakho <yrosomakho=[e-mail]>
Date: Tuesday, 19 August 2025 at 20:22
To: John Mattsson <[e-mail]>
Cc: Peter C <[e-mail]>, Filippo Valsorda <[e-mail]>, TLS List <[e-mail]>
Subject: Re: [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
I believe OpenSSL 3.5 supports both ML-DSA ([1], [2]) and SLH-DSA ([3], [4]) primitives operations for keys and signatures. However it does not mean they are supported as signature algorithms in TLS.

-yaroslav

1. https://docs.openssl.org/3.5/man7/EVP_SIGNATURE-ML-DSA/
2. https://docs.openssl.org/3.5/man7/EVP_PKEY-ML-DSA/
3. https://docs.openssl.org/3.5/man7/EVP_SIGNATURE-SLH-DSA/<https://docs.openssl.org/3.5/man7/EVP_SIGNATURE-SLH-DSA/#description>
4. https://docs.openssl.org/3.5/man7/EVP_PKEY-SLH-DSA/


On 19 Aug 2025, at 10:29, John Mattsson <john.mattsson=[e-mail]> wrote:

I had the memory that Victor said so in the TLS thread about OpenSSL 3.5 supporting ML-KEM, ML-DSA, and SLH-DSA. But looking it up Victor only mentioned ML-DSA. Thanks for the clarification.

Cheers,
John

From: Peter C <Peter.C=[e-mail]>
Date: Tuesday, 19 August 2025 at 18:46
To: Filippo Valsorda <[e-mail]>, John Mattsson <[e-mail]>
Cc: TLS List <[e-mail]>
Subject: RE: [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3
It added support for draft-ietf-lamps-x509-slhdsa, not for this.

Peter

From: Filippo Valsorda <[e-mail]>
Sent: 19 August 2025 17:34
To: John Mattsson <john.mattsson=[e-mail]>
Cc: TLS List <[e-mail]>
Subject: [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

2025-08-19 17:34 GMT+02:00 John Mattsson <john.mattsson=[e-mail]<mailto:[e-mail]>>:

To my understanding, OpenSSL 3.5 LTS already uses the unregistered numbers in the draft.

I also had that impression, but Viktor corrected me in another thread. See excerpt below.

2025-05-19 13:53 GMT+02:00 Viktor Dukhovni <[e-mail]<mailto:[e-mail]>>:
On Mon, May 19, 2025 at 01:29:40PM +0200, Filippo Valsorda wrote:

> 2025-05-19 12:41 GMT+02:00 John Mattsson <[e-mail]<mailto:[e-mail]>>:

> > OpenSSL 3.5 has already shipped with the Values 0x0911 – 0x91C that
> > are in the draft.
>
> Frankly, this is a bit irritating, especially given the precedent of
> seed encodings, where we all got saddled with a fractal encoding to
> appease the "legacy" of a handful of early adopters. Now OpenSSL ships
> a production feature in a LTS version with 12 commandeered
> unregistered codepoints from the public range. Ok.

OpenSSL 3.5 DOES NOT have TLS codepoints for SLH-DSA.  I don't know
where John Mattsson got that impression.  The only PQ signature TLS
codepoints in OpenSSL 3.5 are:

    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme

    0x0904  mldsa44     N   [draft-tls-westerbaan-mldsa-00]
    0x0905  mldsa65     N   [draft-tls-westerbaan-mldsa-00]
    0x0906  mldsa87     N   [draft-tls-westerbaan-mldsa-00]


_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]


This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.