Hi, Eric Rescorla wrote: >1. Form a WG opinion on whether we need to do simultaneous PQ + T at all.
I think this is the wrong question. PQ + T is not a requirement or a use case. The right questions is: 1a. Form a WG opinion on whether we need something more conservative than standalone ML-DSA. If the answer is yes, I think draft-reddy-tls-slhdsa is vastly superior to the other suggestions, while draft-reddy-tls-composite-mldsa is vastly inferior. https://www.ietf.org/archive/id/draft-reddy-tls-slhdsa-02.html Dual Certificates and Multiple Certificate/CertificateVerify would be acceptable: they avoid the combinatorial explosion, the regulatory issues, and the vulnerabilities associated with malleable composites. According to government definitions, composites should preserve the security properties of their components. The IETF has done a good job with KEMs in this regard. I find it absurd that we are even discussing composite signatures that significantly weaken the security properties of ML-DSA by removing its BUFF properties and introducing malleability vulnerabilities. The discussion here applies to both the signature_algorithms and signature_algorithms_cert extensions. PQ/T composites cannot be used for long-term roots of trust. Many jurisdictions are discussing regulatory requirements for PQC, and it is very unclear whether quantum-vulnerable algorithms can be retained long term across all of them. This creates a significant business risk even with well-designed composites. The risk is further substantially amplified by composites that significantly weaken the security properties of ML-DSA. Cheers, John Preuß Mattsson From: Eric Rescorla <[email protected]> Date: Thursday, 25 June 2026 at 20:17 To: <[email protected]> Subject: [TLS] Upleveling on PQ + T signatures for TLS Hi folks, We now have a number of proposals for somehow using both PQ + T signatures simultaneously for TLS. These include: - Dual Certificates: draft-yusef-tls-pqt-dual-certs - Composite Certificates: draft-reddy-tls-composite-mldsa - Multiple Certificate/CertificateVerify: https://mailarchive.ietf.org/arch/msg/tls/dVj5I_s8Hj5s4Fzmbv73qac_Ftk/ It seems to me that all of these share the same basic intuition, namely that it's more secure to use both PQ + T algorithms together instead of individually. It's not clear to me whether all of these approaches have the same security properties, but it seems likely that with enough work they can be made to the deliver on the basic value proposition of robust authentication as long as one of the algorithms is strong [0]. To that end, rather than considering each of these ideas individually I would instead suggest that we do the following: 1. Form a WG opinion on whether we need to do simultaneous PQ + T at all. 2. Assuming the answer to (1) is yes then try to pick one approach for doing it. -Ekr [0] I'm ignoring for the moment the policy considerations that are required to make this work. Obviously, you don't get this value proposition if you simultaneously allow the weak algorithm on its own.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
