Angela Robinson from NIST recently summarized the situation as. "The key-derivation methods described in NIST SP 800-56C are currently only applicable to shared secrets established during a key establishment scheme as specified in NIST SP 80056A or 800-56B, or to Z = Z’||T which is the combination of shared secret Z’ that was generated as specified in SP 800-56A or -56B with another shared secret T that is generated in any way. As previously stated, NIST intends to allow all key-derivation methods in NIST SP 800-56C to apply to the outputs of the ML-KEM key establishment scheme specified in FIPS 203.
Further, NIST intends to allow the 800-56C key derivation methods to apply to shared secrets of the form Z = T || Z’, where T and Z’ are as described above but in reverse order. That is, we will ensure that either order is allowed for FIPS validation in upcoming revisions to -56C. Note, however, that the order of the shared secrets will need to be specified at the protocol level to avoid confusion. We are working on guidance to ensure that this reordering will not introduce security vulnerabilities. NIST is open to feedback on the matter." https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0/m/hEMfXBFHCgAJ <https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0/m/hEMfXBFHCgAJ> https://csrc.nist.gov/news/2024/public-comments-requested-on-the-sp-800-56-subseri <https://csrc.nist.gov/news/2024/public-comments-requested-on-the-sp-800-56-subseri> So it is not correct as I wrote that X25519MLKEM768 is NIST approved yet but X25519MLKEM768 and MLKEM768 will be soon. NIST does not need to approve X25519. ML-KEM is used as Z and T can be anything including X25519. The second change applies to SecP256r1MLKEM768, which is currently approved, and with the suggested change would continue to be approved even when P-256 is not. Cheers, John From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Date: Sunday, 15 December 2024 at 19:15 To: John Mattsson <[email protected]>, Stephen Farrell <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement >It is obvious that pure PQ KEMs are the future I am not sure about that. X25519MLKEM768 is already quickly becoming the new de facto standard (google.com, ericsson.com, government.se, etc. are already using it, likely thanks to Cloudflare). Do you seriously expect governments and standards bodies to keep approving X25519 component after CRQC existence becomes public knowledge? What purpose would it serve then? It is already compliant with NIST specifications and soon it will be possible to get FIPS certification. Not clear that the benefits of migrating from X25519MLKEM768 to MLKEM768 will be worth it performance and marketing wise. Do you mean that, e.g., NIST will keep then-broken X25519 in the standard until MLKEM is obsoleted too? It is not impossible – but I find it rather hard to believe. From: Stephen Farrell <[email protected]> Date: Sunday, 15 December 2024 at 15:33 To: Blumenthal, Uri - 0553 - MITLL <[email protected]> Cc: [email protected] <[email protected]> Subject: [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement Hiya, On 15/12/2024 02:33, Blumenthal, Uri - 0553 - MITLL wrote: > Stephen, I don’t think attempting to develop consensus in this case > would be either useful or productive. Strongly disagree. I think we ought consider it our duty to develop guidance for those deploying e.g. TLS now that we're adding a plethora of new ciphersuites, some useful, some way less so, and some possibly even risky. >... > Thus, I don’t think there’s a way to bring these two camps together, > nor do I see a need for that. I have no desire to affect the opinions of the sigint agencies who have come up with 100% contradictory positions. It's not them I care about at all, but rather those deploying the set of protocols we develop here. > Let TLS offer both hybrid and pure > KEMs. For TLS, that's inherent in our current IANA regisration model and has already happened. > And be done with it. My point is that we are not done with it - we should be offering guidance on what to use when. If we do not do that, IMO we'd be doing a disservice to the Internet community. Cheers, S.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
