Sidestepping hybrid standardisation is an advantage, but I'm not yet ready to admit failure there.
On Sun, Jul 27, 2025 at 12:08 PM John Mattsson <john.mattsson= [email protected]> wrote: > I would like to use SLH-DSA for CertificateVerify in use cases where the > performance of SLH-DSA is acceptable. There are simple no other solutions. > Standalone ML-DSA is not an option in Europe. Hybrid ML-DSA is not mature > and might never be. Mobile networks are not enterprise. TLS is so much more > than the Web… > > > > Cheers, > > John > > > > *From: *David Benjamin <[email protected]> > *Date: *Sunday, 27 July 2025 at 12:01 > *To: *John Gray <[email protected]> > *Cc: *Scott Fluhrer (sfluhrer) <[email protected]>, TLS > List <[email protected]> > *Subject: *[TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3 > > Note that enterprise PKI and this draft are not the same thing. This draft > is proposing to add it to enterprise PKI *and* online TLS keys. > > > > The right way to do this for just PKI use cases is to define the > codepoints to only do anything for the X.509 half of their use in TLS, not > the CertificateVerify half. We've got precedent elsewhere in TLS when we > wanted a codepoint to only apply to one of the two. > > > > On Fri, Jul 25, 2025 at 11:59 PM John Gray <John.Gray= > [email protected]> wrote: > > I am also in favor of adoption. Support of SLH-DSA is definitely in > scope for enterprise PKI. > > Side note: As an author I am obviously willing to review and update the > text. > > > > John Gray > > > ------------------------------ > > *From:* Scott Fluhrer (sfluhrer) <[email protected]> > *Sent:* Friday, July 25, 2025 3:52 AM > *To:* Sean Turner <[email protected]>; TLS List <[email protected]> > *Subject:* [EXTERNAL] [TLS] Re: Second WG Adoption Call for Use of > SLH-DSA in TLS 1.3 > > > > *WARNING: This email originated outside of Entrust.* > > DO NOT CLICK links or attachments unless you trust the sender and know the > content is safe. > > > > I am in favor of adoption. > > > > Obligatory bias notice: I am a coauthor... > > > ------------------------------ > > *From:* Sean Turner <[email protected]> > *Sent:* Friday, July 25, 2025 3:26 AM > *To:* TLS List <[email protected]> > *Subject:* [TLS] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3 > > > > Hi! Just a reminder that this call closes on Monday. > > spt > > > On Jul 15, 2025, at 00:05, Sean Turner <[email protected]> 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/ > <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/o4KnXjI-OpuHPcB33e8e78rACb0/__;!!FJ-Y8qCqXTj2!bc6KPPlbV1BIFSmZov7hU__2WOWvYV0O7i5-1irnPiPymL0TA1qyqa9d_nFbl3bc8xF6UjDczsVnPaso9vI55nvaaPhT6P_9$> > > [1] > https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/ > <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/tls/hhLtBBctK5em6l82m7rgM6_hefo/__;!!FJ-Y8qCqXTj2!bc6KPPlbV1BIFSmZov7hU__2WOWvYV0O7i5-1irnPiPymL0TA1qyqa9d_nFbl3bc8xF6UjDczsVnPaso9vI55nvaaA_am_4m$> > > [2] https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/ > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/__;!!FJ-Y8qCqXTj2!bc6KPPlbV1BIFSmZov7hU__2WOWvYV0O7i5-1irnPiPymL0TA1qyqa9d_nFbl3bc8xF6UjDczsVnPaso9vI55nvaaFNOjbCO$> > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > *Any email and files/attachments transmitted with it are intended solely > for the use of the individual or entity to whom they are addressed. If this > message has been sent to you in error, you must not copy, distribute or > disclose of the information it contains. Please notify Entrust immediately > and delete the message from your system.* > > _______________________________________________ > 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]
