I also support adoption of the draft. If there is a use case for 3gpp, I'm ok with that.
On Sat, 19 Jul 2025 at 22:49, Simon Josefsson <simon=40josefsson....@dmarc.ietf.org> wrote: > > I support adoption of the draft, and believe SLH-DSA in TLS would be > useful and that a stable reference in the form of an RFC would be good. > > I think the people who have concerns with the performance assume the > intended use is for regular web browser HTTPS use, but TLS has broader > applicability than that. 50kb sizes is peanuts for the majority of > applications today, and you may compare with 1MB handshakes as for > Classic McEliece [1] which is still performant for many use-cases. > Performance on modern machines are negligible, slower than what RSA was > in SSL 30 years ago on then typical machines. So I would disagree with > the notion that SLH-DSA is slow, and suggest that we let users decide > how to balance performance to (perceived) security. > > /Simon > > [1] > https://www.wolfssl.com/announcing-mcwolf-classic-mceliece-support-with-wolfssl/ > > Sean Turner <s...@sn3rd.com> writes: > > > 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
