Hi all, I am mostly ambivalent, but slightly leaning positive about SLH-DSAs future in TLS. My thoughts on SLH-DSA in TLS are the following:
Against: - By almost every metric that I have measured TLS handshake performance, SLH-DSA (SPHINCS+) performance is abysmal (handshake size, latency) - The potentially much more relevant parameters with reduced numbers of signatures have not been selected by NIST yet, but are supposed to be upcoming. Pro: - Public keys are tiny, this could be beneficial for devices with limited storage (e.g. as secondary algorithm) - Implementing SLH-DSA, simplified, is essentially slapping a loop on a hash function. This makes its code size very manageable, especially if there is already a (good) hash implementation on a device (as one would likely already ship as part of ML-KEM or ML-DSA). - Some applications might not care about the latency (suggested 3GPP) A secondary question is whether an RFC is necessary, for which I think the same reasoning applies as with ML-DSA. It would be very helpful if more potential users come forward. Cheers, Thom > Op 16 mei 2025, om 23:20 heeft David Benjamin <[email protected]> het > volgende geschreven: > > I share the confusion about what this is for. SLH-DSA is handy, but it seems > to not fit TLS very well at all. > > There's also rather a lot of algorithms proposed to be added here, so I am > correspondingly that many missing use cases worth of confused. > > On Fri, May 16, 2025, 17:06 Watson Ladd <[email protected] > <mailto:[email protected]>> wrote: >> I don't support adoption. >> >> It is not clear to me what an RFC for a ciphersuite is supposed to >> signal. To the extent it indicates this solution is prefered, the fact >> that SLH-DSA is a very awkward fit for server auth makes me think we >> should say no. >> >> Sincerely, >> Watson Ladd >> >> On Fri, May 16, 2025 at 6:28 AM Sean Turner <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > We are continuing with our WG adoption calls for the following I-D: Use of >> > SLH-DSA in TLS 1.3 [1]; see [2] for more information about this tranche >> > of adoption calls. 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. This call will close at 2359 UTC on 30 May 2025. >> > >> > Reminder: This call for adoption has nothing to do with picking the >> > mandatory-to-implement cipher suites in TLS. >> > >> > Cheers, >> > Joe and Sean >> > >> > [1] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/ >> > [2] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/ >> > _______________________________________________ >> > TLS mailing list -- [email protected] <mailto:[email protected]> >> > To unsubscribe send an email to [email protected] >> > <mailto:[email protected]> >> >> >> >> -- >> Astra mortemque praestare gradatim >> >> _______________________________________________ >> TLS mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> > _______________________________________________ > 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]
