I second D.J. Bernstein's concerns, but my other issue with giving options like this is that they will creep up into MTI sets or default sets, with higher priority than hybrids.
I find it less ideal that the document on pure ML-KEM (or signature) and hybrids are disassociated, causing the progress of standardization of the pure version to bring these other concerns. So, as long as everyone is on the same page that pure is just one option, perhaps for strict compliance with CNSA 2.0, then there is no issue from my perspective, but that's a (mildly) controversial part. On Fri, Dec 6, 2024 at 9:29 AM D. J. Bernstein <d...@cr.yp.to> wrote: > Scott Fluhrer (sfluhrer) writes: > > I understand that people want to discuss the hybrid KEM draft more > > (because there are more options there) - can we at least get the less > > controversial part done? > > See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather > than ECC+PQ, would incur security risks without improving deployment. > Regarding "less controversial", you might have missed previous TLS WG > messages such as > > https://mailarchive.ietf.org/arch/msg/tls/j1qkfNmk33OZ7hgCR53TiLmYOiA/ > https://mailarchive.ietf.org/arch/msg/tls/I1GPuKLCBJ3jA-ovNcuIsLlNGkM/ > https://mailarchive.ietf.org/arch/msg/tls/gB55YMMdfFLqaCE9ughNXX8qjtA/ > > where various people (including me, obviously) already objected. Also, > you might have missed BSI writing in > > > https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile > > that its post-quantum KEM recommendations are only "in combination with > a classical key derivation mechanism"; commentator Matt Green writing in > > https://x.com/matthew_d_green/status/1742521204026622011 > > that NSA's "stance against hybrid encryption makes absolutely zero > sense"; and NSA itself in > > > https://web.archive.org/web/20220524232250/https://www.nsa.gov/Portals/75/documents/resources/everyone/csfc/threat-prevention.pdf > > asking for two cryptographic layers "to mitigate the ability of an > adversary to exploit a single cryptographic implementation". > > ---D. J. Bernstein > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
