It would in fact be great to get an official answer on whether either order is FIPS-compatible, as it clear that the order doesn't matter for security when used in TLS 1.3 as written in tls-hybrid-design (fixed lengths, everything public is going into the key schedule anyway, etc).
There are other settings / combiners where the order can matter but this design in TLS 1.3 is not one On Thu, Oct 17, 2024 at 9:10 AM Kris Kwiatkowski <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> > 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> >> 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 >> > _______________________________________________ > 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
