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> 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> > <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. > > 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/ to learn about how we use this > information. > _______________________________________________ > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
