D. J. Bernstein wrote: >(1) common-sense ECC+PQ; (2) damaging security with solo PQ.
You are comparing apples and oranges. Standalone SLH-DSA and ML-DSA are mature solutions that can be deployed in PKI and TLS today. “ECC+PQ” is not a solution; it is a broad design space of potential solutions, none of which are mature. Please point to a concrete technical ECC+PQ TLS signature solution and explicitly acknowledge that any such hybrid approach would significantly delay PQC migration, to the extent that industry would miss European 2030 deadlines. The PQC migration is urgent. If one believe a CRQC will emerge in 2040, we should already have completed migration of end-entity certificates in long-lived devices to PQC, as we know empirically that many consumer devices have lifetimes of 15 years and will continue to use the public keys with which they were provisioned. That standalone SLH-DSA or standalone ML-DSA would damage security is very speculative. What is very clear is that draft-ietf-lamps-pq-composite-sigs would 100% damage important security properties, not only compared to standalone SLH-DSA and ML-DSA, but also compared to standalone EdDSA and RSA. Stephen Farrell wrote: >There's also: (3) experiment with PQ authentication in TLS while recommending >against production deployment at this time. That is a discussion worth having. Just as there are fundamental differences between key exchange and authentication, there are also important distinctions between roots of trust used for authentication and end-entity public keys used for authentication. Likewise, there is a significant difference between cloud services that can rotate their public keys weekly and long-lived devices that may be unable to update their public keys over a 15-year lifetime. I think the TLS discussion is too focused on end-entity public keys in cloud services that can be rotated frequently. TLS also relies on roots of trust, and it is widely deployed in long-lived devices where key update is difficult or infeasible over decades. Cheers, John Preuß Mattsson From: Stephen Farrell <[email protected]> Date: Thursday, 4 June 2026 at 02:04 To: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [TLS] Re: [Last-Call] Re: Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC Hiya, On 04/06/2026 00:29, D. J. Bernstein wrote: > IETF does not control software engineering. It_does_ control which TLS > options it will endorse. At that layer, there are currently two choices: > (1) common-sense ECC+PQ; (2) damaging security with solo PQ. I disagree. There's also: (3) experiment with PQ authentication in TLS while recommending against production deployment at this time. Were (3) an IETF-consensus position, IMO publishing this document as an RFC would not be problematic. Cheers, S.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
