> Standalone ML-DSA is not an option in Europe. As far as I am aware, there is not a single normative requirement for a hybrid signature in Europe. Even the BSI document [1] that most people cite as support of hybrids is both clearly non-normative (recommendations only), suggesting people _start planning_ and focused primarily on defending against store-now-decrypt-later, where hybrids are already widely deployed. It also notes that many plans are use-case specific, e.g. just because we have a hybrid kex in TLS, doesn't mean that a pure PQC signature wouldn't also make sense.
> 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. I agree with davidben that SLH-DSA makes sense for signatures _on certificates_. While I was originally in favor of adopting this draft simply because SLH-DSA was a winner of the NIST competition, it seems that since then, no one has put forward a grounded-in-reality use case for anything other than SLH-DSA roots of trust. Even for the firmware case, it seems like an SLH-DSA key in hardware could sign a ML-DSA key for use in TLS. It also seems like adoption is not blocking progress on this---FIPS 205 is enough to get code points from IANA. Finally, in the event this is to be adopted, I should hope that we are able to reduce the number of variants down to one or two, not 12. [1]: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Brochure/quantum-safe-cryptography.pdf?__blob=publicationFile&v=6 On Sun, Jul 27, 2025 at 6:09 AM 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]
