This is an important point. There are settings in which you might want a signature which was secure even if you did not have secure key establishment (e.g., where you are signing the data proper) but because TLS signature only cover the handshake, the security benefit here seems quite limited.
I can imagine one scenario in which there might be some value: 1. We have a CRQC so that EC is broken. 2. The lattice-based systems are broken but expensive to attack so that it's practical to attack a long-term key but not attack during the connection and there is still some benefit in using ML-KEM over nothing. 3. We *also* have a non-broken PQ key establishment algorithm. In this case, you could imagine that because SLH-DSA is secure then you could securely negotiate this hypothetical non-broken PQ key establishment algorithm over ML-KEM. However, this seems to assume a lot of facts which don't seem to apply now, which brings us back to this not being a high priority. -Ekr On Wed, Jul 16, 2025 at 7:47 AM Bas Westerbaan <bas= [email protected]> wrote: > Presently all post-quantum *key agreements* registered for TLS are > (essentially) ML-KEM. If ML-KEM is broken, then a TLS connection even using > SLH-DSA can be decrypted passively and can also be actively MitMed. From a > security standpoint, I see little value in using SLH-DSA over (hybrid) > ML-DSA unless you also use a different key agreement. > > I'm not against SLH-DSA in TLS in the future, but it's very far down on > the priority list. > > Best, > > Bas > > > > On Tue, Jul 15, 2025 at 12:07 AM Sean Turner <[email protected]> wrote: > >> We kicked off an adoption call for Use of SLH-DSA in TLS 1.3; see [0]. We >> called consensus [1], and that decision was appealed. We have reviewed the >> messages and agree that we need to redo the adoption call to get more input. >> >> What appears to be the most common concern, which we will take from >> Panos' email, is that "SLH-DSA sigs are too large and slow for general use >> in TLS 1.3 applications". One way to address this concern is to add an >> applicablity statement to address this point. We would like to propose that >> this (or something close to this) be added to the I-D: >> >> Applications that use SLH-DSA need to be aware that the signatures sizes >> are large; the signature sizes for the cipher suites specified herein range >> from 7,856 to 49,856 bytes. Likewise, the cipher suites are considered >> slow. While these costs might be amoritized over the cost of a long lived >> connection, the cipher suites specified herein are not considered for >> general use in TLS 1.3. >> >> With this addition in mind, we would like to start another WG adoption >> call for draft-reddy-tls-slhdsa. If you support adoption with the above >> text (or something similar) and are willing to review and contribute text, >> please send a message to the list. If you do not support adoption of this >> draft with the above text (or something similar), please send a message to >> the list and indicate why. This call will close at 2359 UTC on 28 July 2025. >> >> Cheers, >> Deirdre, Joe, and Sean >> >> [0] >> https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/ >> [1] >> https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/ >> [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/ >> _______________________________________________ >> 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
