My opinion is also unchanged; we should not adopt this document. The precise reason for the current relaxed code point registration rules is to permit registration of code points without requiring the involvement of the TLS WG, allowing us to focus our attention on what is actually important for TLS. This kind of limited applicability algorithm is precisely that kind of case.
-Ekr On Mon, Jul 14, 2025 at 4:06 PM Filippo Valsorda <[email protected]> wrote: > I did not support adoption then and I do not support it now. My issue with > the document was not that it overstated applicability, but its limited > applicability itself, which is not addressed by acknowledging it. > > I don’t see the need to develop an RFC to assign Recommended = N > codepoints in a Specification Required registry for an algorithm of > marginal utility that already has a specification. Just register the > codepoints with reference to the FIPS. > > If the answer is “but it will be less widely implemented without an RFC” > then 1) some projects are applying sub-optimal criteria to choose what to > implement, and 2) that sounds like a good thing for an algorithm with > limited applicability: only those that really know they need it will > implement it. > > 2025-07-15 00:05 GMT+02:00 Sean Turner <[email protected]>: > > 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]
