On Mon, Nov 6, 2023, 10:07 AM Kris Kwiatkowski <k...@amongbytes.com> wrote:
> So, based on FIPS 140-3 I.G., section C.K., resolution 5, [1]. "SP800-186
> does not impact the curves permitted under SP 800-56Arev3. Curves that are
> included in SP 800-186 but not included in SP 800-56Arev3 are not approved
> for key agreement. E.g., the ECDH X25519 and X448 key agreement schemes
> (defined in RFC 7748) that use Curve25519 and Curve448, respectively, are
> not compliant to SP 800-56Arev3…”. This may potentially be a problem, right?
>
> I think to support FIPS requirements properly, we need both shares to be
> generated by FIPS approved methods.
>
Why do we need FIPS hybrids? The argument for hybrids is that we don't
trust the code/algorithms that's new. FIPS certification supposedly removes
that concern so can just use the approved PQ implementation.
NIST specifically tried to permit hybrids with any other curve as I
understand it, via the argument Z. Would be nice if we could get direct
answers here .
>
> Ideally, I would much prefer to have only one combination and then
> X25519-MLKEM768 should be the one.
> Maybe it’s worth to consider another way to go, So, assuming no one wants
> to use P-{256,384}+Kyber for other reason that FIPS, maybe it’s wroth
> trying to “encourage" NIST to allow X-{25519,448} in FIPS (at least if used
> for hybrid key exchange). If anybody is interested in doing that then I’m
> happy to help.
That's minimally a few years before certificates can come with it.
>
>
> As of today, I’m +1 with Panos.
>
> PS: Note that X25519 is allowed in FIPS 140-2 (i.e. see OpenSSL’s
> certification [2]).
>
> [1]
> https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
> [2]
> https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
>
> Kind regards,
> Kris
>
>
>
> > On 6 Nov 2023, at 18:06, Bas Westerbaan <bas=
> 40cloudflare....@dmarc.ietf.org> wrote:
> >
> >
> > On Mon, Nov 6, 2023 at 5:40 PM Kampanakis, Panos <kpanos=
> 40amazon....@dmarc.ietf.org> wrote:
> > > Concretely, after ML-KEM is finished, I was planning to update
> draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint
> for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.
> > Agreed, but I would suggest three (x25519-mlkem768, p256-mlkem768,
> p384-mlkem1024) to cover FIPS and CNSA 2.0 compliance. More than three
> combinations is unnecessary imo.
> >
> > x25519-mlkem768 will be FIPS thanks to mlkem768. Have you seen x25519 is
> in SP 800-186 now? So I say we can leave out p256-mlkem768.
> >
> > Best,
> >
> > Bas
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
