[TLS] Re: draft-connolly-tls-mlkem-key-agreement

[Deirdre Connolly <[e-mail]>]

> 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=
[e-mail]> 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 <[e-mail]>
> *Sent:* Friday, December 6, 2024 3:44 PM
> *To:* [e-mail]
> *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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>