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

[Andrei Popov <[e-mail]>]

  *   We don’t see any need for SecP256r1MLKEM768 at all, I think that should stay RECOMMENDED=N.
What would be the reason for dis-recommending SecP256r1MLKEM768?

A large number of Microsoft’s online properties are subject to regulatory regimes that prevent the use of X25519; these will need P256+MLKEM and P384+MLKEM.

Cheers,

Andrei

From: John Mattsson <john.mattsson=[e-mail]>
Sent: Friday, December 6, 2024 11:17 PM
To: Andrey Jivsov <[e-mail]>; [e-mail]
Subject: [EXTERNAL] [TLS] Re: draft-connolly-tls-mlkem-key-agreement

For Ericsson, we are planning to use X25519MLKEM768 as soon as possible and make that the default choice. We would like X25519MLKEM768 published as an RFC, be RECOMMENDED=Y, and MTI asap. This is already the de facto standard. All standalone ECC (secp256r1, secp384r1, x25519, x448) should soon be made RECOMMENDED=N and secp256r1 and x25519 should soon be removed from MTI.
We want standalone MLKEM1024 for customers wanting compliance with CNSA 2.0. We are fine with RECOMMENDED=N, but we would like it published as an RFC.

We don’t see any need for SecP256r1MLKEM768 at all, I think that should stay RECOMMENDED=N.

In the future we would like to see one or more backup algorithms (BIKE, Classic McEliece, FrodoKEM, HQC, etc…) to MLKEM standardized and some of them hybridized with X25519 be made RECOMMENDED=Y.

Cheers,
Another

From: Andrey Jivsov <[e-mail]<mailto:[e-mail]>>
Date: Friday, 6 December 2024 at 21:45
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[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

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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>