> I would pair secp384r1 with Kyber768 for completely different reasons: > Kyber768 is what the team kyber recommends. Agreed.
> I don't think there are very good reasons for NIST curves here outside > wanting CNSA1 compliance, and for that you need secp384r1 classical > part. And for that, I would pick secp384r1_kyber768. > >From my perspective, the two reasons for including a NIST curves are: 1. To have an option for those who require FIPS compliance. In a short term at least one key agreement scheme should be FIPS-approved. In the long term both of them should be fips-approved. That way, in case security of Kyber768 falls below 112-bits or simply implementation is broken, one can still run key agreement in FIPS compliant manner. In the end, the ultimate goal of hybrid-tls draft is to ensure that at least one of the schemes provides security if the other gets broken. Would be good to use this in FIPS context also. 2. NIST curves are more often implemented in HW than Curve25519. When working with chips like ATECC608B, one ideally only adds SW-based Kyber and can reuse existing HW-based ECDH. Such migration is simpler, less risky and time-consuming than adding SW-based X25519. To accelerate migration, the hybrid-tls draft should move forward rather quickly and be useful variety of use-cases. Hence, I suggest we assign two codepoints one for X25519-Kyber768 and the other for ECDH/p256-Kyber768. X25519 and P256 provide same security level, from my old days in Cloudflare I remember both schemes were used quite often in TLS, so I hope this choice is not to controversial. Regarding CNSA, I've no experience with national security systems, but does it actually allows to use hybrid schemes? it seems to me that neither 1.0 nor 2.0 allows usage of hybrid schemes (SP800-56C is mentioned but in regards to ECDH, not KDF). Maybe those needs can be addressed at later stage? Kind regards, --- Kris Kwiatkowski Staff Cryptography Architect PQShield _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
