Hi, I strongly support adoption of this draft. I find support of SLH-DSA in TLS 1.3 very useful. With many governments and organizations forbidding use of standalone ML-DSA, SLH-DSA is required. With governments requiring migration of all existing _deployments_ by 2030-2035, the need for standards is urgent. There is absolutely no time to wait, migration of PKI often takes a decade. This is very high priority.
Hybrid signatures are not mature with both standards and implementations lacking, there are also a lot of different standards for hybrid signatures, which makes things worse. With migration of PKI taking significant time, I see standalone ML-DSA and standalone SLH-DSA as the only choices. For many infrastructure use cases of TLS/DTLS/QUIC, the performance of the initial handshake is not very important. OpenSSL 3.5 LTS already has support of SLH-DSA. I think Tiru's statement "SLH-DSA is intended to be leveraged in 3GPP deployments, particularly for long-lived connections" is correct. The use of TLS 1.3 in determined by the TLS profile in TS 33.210. Unless explicitly forbidden, support and use of all PQC algorithms is OPTIONAL/MAY. Algorithms can be used in 3GPP deployments without having been mentioned in 3GPP specifications. And given that ANSSI/BSI/EUCC forbid use of standalone ML-DSA, I don't see any other outcome of the 3GPP work than that both standalone ML-DSA and standalone SLH-DSA will be used. 3GPP has a long security practice of always requiring support of two different algorithms with different constructions for everything. I would strongly expect the same thing here. I am not particularly fond of LSs, but the telecom sector has already sent one LS to TLS WG, if SLH-DSA is not processing quickly, I would expect more..., you have been warned… https://datatracker.ietf.org/liaison/2002/ Cheers, John
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
