So it's pretty clear that TLS 1.3 is FIPS-able, because it has been validated multiple times. But it's not just a blessed exception, or that FIPS is 'not sensitive' to the particulars - it looks to be using HKDF in compliance with SP 800-133rev2 (Section 6.3 Option #3), SP 800-56Crev2, and SP 800-108 - Filippo Valsorda went down the rabbit hole to nail this down: https://words.filippo.io/dispatches/fips-hkdf/
On the hybrids, the orders should match the names to cohere with tls-hybrid-design, and I think the authors intend to at least make the names match the order at least. Whether having different orders amongst different `NamedGroup`s just because one achieves FIPS one way and the other, doesn't (or not as in as many months because of the FIPS crypto module validation lead times), seems a bit gross as these documents are not just serving the handful of implementers deploying hybrid in the next N months, they may last indefinitely and have to serve implementers indefinitely. Minimizing confusion is not nothing On Thu, Oct 17, 2024 at 8:55 AM Eric Rescorla <e...@rtfm.com> 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
