[TLS] Re: Erlang/OTP and Bouncy Castle now supporting SLH-DS A in end-entity certificates

Hi,

Happy to hear that wolfSSL 5.9.3 and OpenSSL 4.1.0 will support SLH-DSA in end-entity certificates! I strongly believe that having it enabled by default is the right approach. Regardless of whether DRS’s proposed polynomial attack on ML-DSA works or not, I think more people will understand that SLH-DSA support is an essential security feature. The trade-off of slightly lower handshake performance should, in my view, be left to the organization deploying the certificate chain without requiring configuration on the other peer.

We have successfully interoperability-tested all combinations between Erlang/OTP, Bouncy Castle, and wolfSSL. We will soon interoperability-test OpenSSL 4.1.0. Our internal recommendations for use in products and services rank TLS libraries based on support for:

- SLH-DSA-SHAKE in both CA and leaf ​certificates
- ML-DSA-44/65/87 in both CA and leaf certificates
- X25519MLKEM768 and ML-KEM-512/768/1024

So far, Bouncy Castle 1.85, Erlang/OTP 29.0.4, and wolfSSL 5.9.3-pre-1e5216e are the only libraries to receive 4 stars. We reserve 5 stars for future libraries that also support HQC-KEM.

>Are these enabled by default, or merely available when explicitly
>configured on both ends?

In Erlang/OTP, SLH-DSA is enabled by default.

>The signing performance of SLH-DSA makes it a generally poor choice
>for TLS on the public Internet.  Which SLH-DSA variants do you
>consider as viable for deployment in TLS?

For our non-Web TLS use cases, I think all of them are viable. I would use the 's' variants for CA certificates and the 'f' variants for public keys in end-entity certificates. I would prefer to use only SHAKE. We try to avoid SHA-2 in new systems, and the specification of SLH-DSA-SHA2 is considerably more complex, whereas SLH-DSA-SHAKE is relatively simple. Regarding security levels, I think the Level 1 hash-based signatures (i.e., the 128 variants) are sufficient for all use cases. However, we will likely use Levels 3 and 5 because of the misconception in some EU guidance that Grover’s algorithm poses a practical threat to Level 1 and 2.

>Keep in mind that Apple M-series cores perform much better than
>anything else for most cryptographic operations.
>
>x64 cores perform at least ~50% worse:

Apple deserves a big round of applause for taking cryptography seriously. x64 CPU vendors, on the other hand, should be ashamed of having dedicated instructions for SHA-1 but not Keccak. Fortunately, (Turbo)SHAKE is quite performant even without dedicated hardware acceleration.

Cheers,
John Preuß Mattsson

From: Viktor Dukhovni <[email protected]>
Date: Friday, 14 August 2026 at 17:46
To: [email protected] <[email protected]>
Subject: [TLS] Re: Erlang/OTP and Bouncy Castle now supporting SLH-DSA in end-entity certificates

On Fri, Aug 14, 2026 at 08:04:56PM +1000, Viktor Dukhovni wrote:

> > While several TLS libraries have supported SLH-DSA in CA certificates
> > for some time, I’m happy to report that both Erlang/OTP [1] and Bouncy
> > Castle now support SLH-DSA as the public key in end-entity
> > certificates. They also support ML-DSA and ML-KEM. SLH-DSA performance
> > is adequate for all of our telecom use cases.
>
> Are these enabled by default, or merely available when explicitly
> configured on both ends?
>
> > Have I missed any other TLS libraries with comparable support?
>
> The signing performance of SLH-DSA makes it a generally poor choice
> for TLS on the public Internet.  Which SLH-DSA variants do you
> consider as viable for deployment in TLS?  On an Apple M3:
>
> [...]
>
> The code points are easy enough to add, but I'm reluctant to enable them
> by default.  And unlike the case with supported groups OpenSSL for now
> does not have a default supported signature algorithms list that would
> exclude these if advertised as TLS signature algorithms by a "provider".
>
> So I'd probably first want to set an explicit signature algorithms list
> in the default configuration file that limits the signature algorithms
> list to a widely used "sensible" subset, before adding support for
> SLH-DSA.

It seems that while I busy paying attention to other matters, the
OpenSSL "master" branch already had the new code points (which were
easily added) both implemented and enabled by default.

I'm not sure that "enabled by default" is the right outcome, though of
course signers can always decline to field signature algorithms they
consider to be too expensive.  So the risk is exposure to somewhat more
expensive verification cost, and a somewhat larger "attack surface".

It is not yet 100% settled that the SLH-DSA will remain enabled by
default by the final 4.1.0 release, but that is the most likely outcome
unless others share my hesitation about enabling all or any of the
SLH-DSA variants by default, without explicit configuration making it so.

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

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

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