On Thu, Jun 25, 2026 at 11:08 PM John Mattsson <[email protected]> wrote:
> 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 > Hi John, I think we could break this apart into 1(a) [your question] and then 1(b) [my question]. My reasoning here is that SLH-MLDSA just requires a code point registration and not any new protocol engineering (although the size may be a problem in question). -Ekr > 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]
