> Hence, Cisco will implement it; I am essentially just asking for code points.
Code points have been allocated: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.ietf.org/archive/id/draft-connolly-tls-mlkem-key-agreement-05.html#name-iana-considerations On Fri, Dec 6, 2024, 5:23 PM Scott Fluhrer (sfluhrer) <sfluhrer= 40cisco....@dmarc.ietf.org> wrote: > Well, I am on the same page that ‘pure ML-KEM’ should be one option. > While I would agree with you that hybrid makes sense (and should be another > option), I am not as inclined as some people to say “and that is so clearly > the right trade-off that we should forbid any other option”. There are > people whose cryptographic expertise I cannot doubt who say that pure > ML-KEM is the right trade-off for them, and more importantly for my > employer, that’s what they’re willing to buy. Hence, Cisco will implement > it; I am essentially just asking for code points. > > > > As for it accidentally becoming “MTI”, well I’m pretty sure that won’t > happen (barring Q-day happening and the current hybrid key exchanges no > longer making sense). > > > > As for people implementing it instead of hybrid, well, the working group > can help to prevent that by moving ahead with the hybrid draft (hint, hint). > > > > *From:* Andrey Jivsov <cry...@brainhub.org> > *Sent:* Friday, December 6, 2024 3:44 PM > *To:* TLS@ietf.org > *Subject:* [TLS] Re: draft-connolly-tls-mlkem-key-agreement > > > > 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 > <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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
