I’m with David Benjamin on this.
— Regards, Uri
Secure Resilient Systems and Technologies MIT Lincoln Laboratory On Jul 16, 2025, at 11:33, David Benjamin <david...@chromium.org> wrote:
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.
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
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 < e...@rtfm.com> 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
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
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 -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
|
smime.p7s