>Yes, I was wondering if there is a concrete plan to relax the ordering >requirement. After >yesterday's meeting, I understood that this is something >NIST may consider.
I think it would make even more sense if NIST just approved X25519 and X448. The vast majority of TLS/HTTPS/QUIC/SSH connections today already use X25519. It would make sense if NIST approved this. NIST has already specified Curve25519 and Curve448 in SP 800-186. The Montogomery curves are faster, have better encoding, and are more robust than Weierstraß curves. Ericsson's plan is to use as much x25519, x448, Ed25519, and Ed448 as possible in PQC hybrids. We also plan to use as much SHA-3/SHAKE/cSHAKE/KMAC as possible. Cheers, John From: Kris Kwiatkowski <k...@amongbytes.com> Date: Friday, 18 October 2024 at 13:36 To: Deirdre Connolly <durumcrustu...@gmail.com> Cc: CJ Tjhai <cjt=40post-quantum....@dmarc.ietf.org>, draft-kwiatkowski-tls-ecdhe-mlkem.auth...@ietf.org <draft-kwiatkowski-tls-ecdhe-mlkem.auth...@ietf.org>, TLS List <tls@ietf.org> Subject: [TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02 Just to clarify Kris, you are _asking_ if there is a plan? I don't know if Quynh can comment but Yes, I was wondering if there is a concrete plan to relax the ordering requirement. After yesterday's meeting, I understood that this is something NIST may consider. [1] See Mike's notes https://mailarchive.ietf.org/arch/msg/spasm/0HYpMgRiqUF61Z90BYuS-RfBWDU/ NIST have said publicly that they plan to clarify hybrid KEMs in the forthcoming SP 800-227: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/6_D0mMSYJZY/m/3DwwIAJXAwAJ > is there a plan to change SP800-56Cr2, so that it allows to > use combination of two shared secrets where one was generated by FIPS-approved > technique, BUT concatenated in any order. On Thu, Oct 17, 2024 at 9:10 AM Kris Kwiatkowski <k...@amongbytes.com<mailto:k...@amongbytes.com>> wrote: Indeed, that would be good inside. Additionally, is there a plan to change SP800-56Cr2, so that it allows to use combination of two shared secrets where one was generated by FIPS-approved technique, BUT concatenated in any order. I understand it is potentially more complicated for ACVP testing, but it seems it would solve a problem. Does order matter from the security perspective? On 17/10/2024 13:53, Eric Rescorla wrote: Can we get a ruling on this from NIST? Quynh? -Ekr On Thu, Oct 17, 2024 at 2:32 AM Joseph Birr-Pixton <jpix...@gmail.com<mailto:jpix...@gmail.com>> wrote: Please could we... not? It certainly is one interpretation of that section in SP800-56C. Another is that TLS1.3 falls outside SP800-56C, because while HKDF kinda looks like section 5, none of the allowed options for key expansion specified in SP800-108 (and revs) are the same as HKDF-Expand. "KDF in Feedback Mode" gets close, but (ironically) the order and width of inputs are different. Given people have shipped FIPS-approved TLS1.3 many times by now (with approved HKDF implementations under SP800-56C!), we can conclude that FIPS approval is simply not sensitive to these sorts of details. I also note that tls-hybrid-design says: > The order of shares in the concatenation > MUST be the same as the order of algorithms indicated in the > definition of the NamedGroup. So we're not even being consistent with something past WGLC? Thanks, Joe On Thu, 17 Oct 2024 at 08:58, Kris Kwiatkowski <k...@amongbytes.com<mailto:k...@amongbytes.com>> wrote: Yes, we switched the order. We want MLKEM before X25519, as that presumably can be FIPS-certified. According to https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf, section 2, the shared secret from the FIPS-approved algorithm must precede the one that is not approved. X25519 is not FIPS-approved hence MLKEM goes first. P-256 is FIPS-approved. The ordering was mentioned a few times, and there was some discussion on github [1] about it. But, maybe the conclusion should be just to change the name X25519MLKEM768 -> MLKEM768X25519 (any opinion?) That would be just a name change, so the code point value should stay the same. Cheers, Kris [1] https://github.com/open-quantum-safe/oqs-provider/issues/503#issuecomment-2349478942 On 17/10/2024 08:24, Watson Ladd wrote: Did we really switch the order gratuitously on the wire between them? On Thu, Oct 17, 2024 at 12:02 AM CJ Tjhai <cjt=40post-quantum....@dmarc.ietf.org><mailto:cjt=40post-quantum....@dmarc.ietf.org> wrote: Hello, The X25519MLKEM768 scheme defined in the document is a concatenation of MLKEM768 and X25519, why is it not named MLKEM768X25519 instead? For SecP256r1MLKEM768, the naming makes sense since it's a concatenation of P256 and MLKEM768. Apologies if this has already been asked before. Cheers, CJ ________________________________ PQ Solutions Limited (trading as ‘Post-Quantum’) is a private limited company incorporated in England and Wales with registered number 06808505. This email is meant only for the intended recipient. If you have received this email in error, any review, use, dissemination, distribution, or copying of this email is strictly prohibited. Please notify us immediately of the error by return email and please delete this message from your system. Thank you in advance for your cooperation. For more information about Post-Quantum, please visit www.post-quantum.com<http://www.post-quantum.com/>. In the course of our business relationship, we may collect, store and transfer information about you. Please see our privacy notice at www.post-quantum.com/privacy-policy/<http://www.post-quantum.com/privacy-policy/> to learn about how we use this information. _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
