Soatok Dreamseeker <[email protected]> writes: > As someone who *prefers* hybrid KEMs, I do not believe the same > argument holds for hybrid signatures. There is no analogous "harvest > now, decrypt later" against signature schemes. They can only be > exploited once a CRQC exists, and not a moment sooner. The pre-QC > algorithmic risk of pure ML-DSA vs hybrid ML-DSA is significantly > lower than that of ML-KEM vs hybrid ML-KEM.
They can be exploited when, for example, any pre-quantum implementation bug is identified. You can't have end-to-end confidentiality without authentication, and TLS uses signatures for authentication. Thus you could make an argument that PQ-hybrid signatures is more important than PQ KEMs, since signatures are a requirement to have ANY kind of confidentiality guarantees. Otherwise we are back to the old 1990's world of no protection against active man-in-the-middle attacks. Which is a nice situation to be in for state-run attackers. Given the popular use of man-in-the-middle proxies serving large parts of the WWW these days, such attacks are feasible. My argument is that using new PQ crypto in hybrid with traditional crypto is a reasonable and an appropriate measurement to protect against throwing out the baby with the bathing water. The cost of hybrids is motivated by the risks involved. Diminishing these risks, and exaggerating the costs, leads everyone in the wrong direction. /Simon > > On Sun, Apr 12, 2026 at 5:51 AM Simon Josefsson <simon= > [email protected]> wrote: > >> Bas Westerbaan <[email protected]> writes: >> >> > On Sun, Apr 12, 2026 at 11:35 AM Simon Josefsson <simon= >> > [email protected]> wrote: >> > >> >> I've re-read the document and continue to believe that this work ought >> >> not to be published through the TLS WG. There are other publication >> >> venues available for crypto algorithm registrations, and I believe using >> >> our time in the WG on non-hybrid KEM's to be a bad idea because of all >> >> the concerns expressed throughout the life of this document. >> >> >> > >> > Simon, just to be sure you read the right document: this thread is not >> > about KEMs. >> >> Thanks for the catch - one week of vacation in the sun tends to re-set >> the terminology brain :) >> >> Please read my comment replacing 'non-hybrid KEM' with 'non-hybrid >> PQ-Signature' above, and replace 'throughout the life of this document' >> with 'by earlier discussions on the insecurity of non-hybrid PQ usage'. >> >> /Simon >> >> > >> > >> >> >> >> /Simon >> >> >> >> Sean Turner <[email protected]> writes: >> >> >> >> > This is the working group last call for Use of ML-DSA in TLS >> >> > 1.3. Please review draft-ietf-tls-mldsa [1] and reply to this thread >> >> > indicating if you think it is ready for publication or not. If you do >> >> > not think it is ready please indicate why. This call will end on April >> >> > 23, 2026. >> >> > >> >> > REMINDER: If you have not done so recently, review the TLS WG's Mail >> >> List Procedures; see [2]. >> >> > >> >> > The Chairs, >> >> > Deirdre, Joe, and Sean >> >> > >> >> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/ >> >> > [2] >> >> https://mailarchive.ietf.org/arch/msg/tls/ucdImHExlbOf4Q3BCG81gjzi2xE/ >> >> > >> >> > _______________________________________________ >> >> > 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] >> > >> _______________________________________________ >> 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] >
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
