On Wed, 16 Jul 2025 at 19:27, Matt G1 <matt...@ncsc.gov.uk> wrote: > > > Hello all, > > > > I think it’s premature to say that 3GPP intends to use SLH-DSA. The 3GPP > security group (SA3) will start its PQ migration study at its next meeting. > As such no discussions about which algorithms are > required/preferred/desired has happened at this stage. > > > > Details of the study parameters/scope can be found here for the curious: > > > > > https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_108_Prague_2025-06/Docs/SP-250858.zip >
Just to clarify my earlier message: I didn't mean to imply that 3GPP has decided to adopt SLH-DSA. What I intended to convey is that use of SLH-DSA in TLS is mentioned as one of the NIST-selected algorithms in the draft SID for the PQC study in SA3, available here: https://www.3gpp.org/FTP/Meetings_3GPP_SYNC/SA3/Inbox/Drafts/draft_S3-252154-r1_PQC%20SID.docx. TLS-based protocols are increasingly used to secure long-lived interfaces in critical infrastructure, including mobile networks. For example, DTLS-in-SCTP is required in 3GPP for several interfaces (such as N2), which rely on long-lived TLS connections. The argument that SLH-DSA is not ideal for TLS, but I believe this comment comes from HTTP use cases. In contrast, for infrastructure use cases where large volumes of data are transferred over long-lived connections, the additional few kilobytes in the handshake are comparatively negligible. Cheers, -Tiru > > > Regards, > > > > Matt > > > > The Standards Person > > NCSC Telecoms Security Consultant > > > > > > > > *From:* tirumal reddy <kond...@gmail.com> > *Sent:* 16 July 2025 12:46 > *To:* Sean Turner <s...@sn3rd.com> > *Cc:* TLS List <tls@ietf.org> > *Subject:* [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3 > > > > I support adoption of the draft. SLH-DSA is intended to be leveraged in > 3GPP deployments, particularly for long-lived connections. While it > increases the size of the TLS 1.3 handshake, the impact on connection > performance is minimal in the context of long-lived connections with large > data transfers. > > > > Cheers, > > -Tiru > > > > On Tue, 15 Jul 2025 at 03:37, Sean Turner <s...@sn3rd.com> 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 -- 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