I would add that there is a cost to unnecessary variability in this space. Whether or not SLH-DSA is appropriate for 3GPP (I'm very skeptical it is), it clearly is inappropriate for the vast, vast majority of TLS uses, and not jus HTTP. That means anyone using it would not be on the well-trod path. Decisions like these have a habit of carrying far into the future, beyond their original parameters, so I think you would find yourself constrained by availability of implementations (while we do have one SLH-DSA variant, we certainly have no plans to wire it into our TLS stack!), or the costs of SLH-DSA expanding to cases beyond what you originally scoped.
Obviously, one size does not fit all, and sometimes you *do* want to deviate from the well-trod path. But "we can weather SLH-DSA's costs" is not a compelling reason to do so. You also want a clear security benefit to do so. As Eric and Bas discussed, the case where SLH-DSA actually improves security *for the CertificateVerify signature[*]* are very, very remote. This my recommendation would be: - Do not adopt SLH-DSA for the CertificateVerify signature - 3GPP folks, in your PQ migration study, do not use SLH-DSA If in the future things change and SLH-DSA does become appropriate in this context, we can always define it then. In the unlikely event that happens, hopefully we'll also have a better sense of the space and not try to allocate *12 different algorithms*. We did the excessive zoo of parameters in the early days of EC and that was too much. David [*] Obviously there are cases where SLH-DSA is appropriate for systems. They largely do not apply to TLS. On Wed, Jul 16, 2025 at 11:21 AM Eric Rescorla <[email protected]> wrote: > 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] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
