[TLS] Re: Erlang/OTP and Bouncy Castle now supporting SLH-DS A in end-entity certificates
Viktor Dukhovni <[email protected]>
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <[email protected]> |
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]