On Sun, Dec 15, 2024 at 11:47 PM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> wrote:
> 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. On the wire, X25519MLKEM768 puts the MLKEM shared secret first, so it actually is fine for FIPS (but we still need a FIPS approved module for MLKEM). > > 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 <u...@ll.mit.edu> > Date: Sunday, 15 December 2024 at 19:15 > To: John Mattsson <john.matts...@ericsson.com>, Stephen Farrell < > stephen.farr...@cs.tcd.ie> > Cc: tls@ietf.org <tls@ietf.org> > 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 <stephen.farr...@cs.tcd.ie> > Date: Sunday, 15 December 2024 at 15:33 > To: Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> > Cc: tls@ietf.org <tls@ietf.org> > 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. > > > > > > > > > > > > > _______________________________________________ > 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
