On Thu, Jul 24, 2025 at 5:50 AM tirumal reddy <kond...@gmail.com> wrote: > > On Thu, 24 Jul 2025 at 13:49, Daniel Van Geest > <daniel.vange...@cryptonext-security.com> wrote: >> >> Tiru, >> >> While you haven't requested codepoints, the draft claims them, e.g. >> >> slhdsa_sha2_128s (0x0911), >> >> That is my concern regarding process. > > These are just placeholders, we haven’t requested IANA to assign codepoints > yet. We’ll update the draft to make that clearer.
I generally see people use TBD for them. > > -Tiru >> >> Daniel >> >> On 2025-07-24 12:45 p.m., tirumal reddy wrote: >> >> Thanks Daniel for the support. We have not yet requested codepoints, this >> was intentional. We wanted to allow for more discussion within the WG, >> particularly around the type of codepoints needed. >> >> -Tiru >> >> On Thu, 24 Jul 2025 at 13:29, Daniel Van Geest >> <daniel.vangeest=40cryptonext-security....@dmarc.ietf.org> wrote: >>> >>> I support adoption with the applicability statement. >>> >>> I am guilty of helping spread OID proliferation in >>> draft-ietf-lamps-x509-slhdsa, although that was because we couldn't predict >>> all the use cases for SLH-DSA end-entity certificates. I'm glad this draft >>> only uses the pure half of SLH-DSA, but I hope that it can cut down on the >>> number of codepoints. For example, TLS is currently dependent on SHA-2 for >>> cipher suites, perhaps the SLH-DSA SHAKE options could be removed. Some >>> thought on whether the small or fast versions would be more appropriate for >>> TLS could help then the codepoints to a reasonable number. >>> >>> A point of process: I don't think this draft should have claimed any IANA >>> codepoints, that is for IANA to assign after a request is made. At least, I >>> don't see these in the IANA registry. Is it too late for the draft to >>> remove these values, hopefully reduce the number of codepoints (if >>> adopted), and only request those codepoints from IANA? >>> >>> Regards, >>> Daniel >>> >>> On 2025-07-14 11:05 p.m., Sean Turner 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 > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
