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. -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
