On Fri, May 16, 2025 at 09:27:07AM -0400, Sean Turner wrote:
> If you support adoption and are willing to review and contribute text,
> please send a message to the list. If you do not support adoption of
> this draft, please send a message to the list and indicate why.
I do not support adoption at this point in time. It is not yet clear
which if any variants of SLH-DSA are generally applicable backups to
ML-DSA and/or hybrids.
The performance of SLH-DSA is such that even a modest new connection
rate can strain server CPU resources, so its applicability is likely
limited to non-public networks. For this to be urgent the devices in
question would need to have a very long shelf-life with no opportunity
for software updates once provisioned.
Firmware signing for critical devices is perhaps a plausible use-case,
but use with TLS, that cannot be introduced later as/when needed
(software update), does not look compelling.
On Fri, May 16, 2025 at 01:36:18PM +0000, John Mattsson wrote:
> I support adoption. With many European countries requiring
> hybridization of ML-DSA, and the maturity of hybrid signatures being
> low, support of SLH-DSA is important in all protocols
This may be true in time, but it is far from clear that time is now.
On Sat, May 17, 2025 at 06:02:30AM +0000, John Mattsson wrote:
> >Can the authors -- or anyone actually -- provide a >specific example of
> >where they WANT to use SLH->DSA? Not COULD as the draft currently says.
>
> I would like to support it in all our TLS implementations as a backup
> algorithm to the lattice-based ML-DSA.
It is unclear which "it" (if any) among the various SLH-DSA parameter
sets is a backup candidate for ML-DSA in TLS outside narrow use-cases
with connection rates are low, and DoS not a significant concern.
> People say that SLH-DSA is not a good fit for TLS, but I think they
> mean HTTPS. If you use TLS for infrastructure instead of IPsec and
> transfer high-volumes of data over a long-lived connection, a few kB
> in the handshake are quite irrelevant.
Not just HTTPS, basically any TLS server node connected to public
On Sat, May 17, 2025 at 11:32:20AM +0530, tirumal reddy wrote:
> We would like to leverage SLH-DSA in 3GPP deployments, particularly
> for long-lived connections. While SLH-DSA increases the size of the
> TLS 1.3 handshake, its impact on connection performance is minimal in
> the context of large data transfers, especially over low-loss
> networks.
OpenSSL 3.5 includes support for ML-DSA, with just the IANA code points
assigned. On what timescale does 3GPP need to include support for a
backup PQ *signature* algorithm. There is no record now, decrypt later,
risk involved (as with key exchange), so it seems that deferring this a
year or so down the road should still afford plenty of time for software
updates to make these available when needed.
--
Viktor.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
