randombit
PQC: Add TLS 1.3 groups for ML-KEM-512, -768 and -1024
Those groups are described in draft-connolly-tls-mlkem-key-agreement and propose the registration of code points 0x0512, 0x0768 and 0x1024 by IANA. Alas, IANA did not adopt them as of now. Also, the email exchange on the IETF mailing list shows controversy whether or not it is too early to use standalone PQC for TLS key negotiation.
Nevertheless, think we should provide support for them to give users an easy way to use standalone PQC if they want or have to. Only, I'm wondering whether we should be bullish on the code points and call them TLS::Group_Params::ML_KEM_512 or rather TLS::Group_Params::ML_KEM_512_PRELIMINARY (or similar).
coverage: 91.252% (-0.003%) from 91.255% when pulling 143eadfcc0302b146cc4c7702934b638285044e4 on Rohde-Schwarz:tls/ml_kem into 98655ef1cee61fa41bd423b89aea4c7ca14140a4 on randombit:master.
(but can anyone really not spare the extra 32 bytes for a X25519 or P-256 kex, idk…)
The discussion revolves around compliance, and whether or not hybrid is advised, prohibited or tolerated by certain governmental bodies.
I’d lean towards deferring this to 3.7.0 just to avoid too much proliferation of draft TLS suites.
Agreed. In the mean time, users have the option to integrate custom groups. This even got a little easier with TLS::Callbacks::tls_deserialize_peer_public_key() (#4389).
Already I’m trying to figure out if we can get away with dropping the Kyber r3 suites without too much disruption…
Perhaps its worth looking into generalizing the concept of key exchange groups in TLS to simplify the addition of "custom curves". Currently this is fairly involved with understanding and customizing non-trivial methods in TLS::Policy and TLS::Callbacks. If that was simpler and less error prone, we might just get away with deprecating/removing the draft curves and pointing to a new (simple) interface.
I would argue that users who currently use any of the draft groups probably don't do so in production (hopefully) yet, and are thus able to adapt fairly quickly.
In the best case some (public) curve registration might be as simple as this (ignoring TLS 1.2's explicit DH groups):
register_group_for_code_point(
0x1024, "ML-KEM-1024",
[](RandomNumberGenerator& rng) {
return std::make_unique<ML_KEM_PrivateKey>(rng, ML_KEM_Mode::ML_KEM_1024);
},
[](std::span<const uint8_t> pubkey_bytes) {
return std::make_unique<ML_KEM_PublicKey>(key_bits, ML_KEM_Mode::ML_KEM_1024);
});
Oh no! The 05-revision of the document adapts the code points to 0x0200 (512), 0x0201, and 0x0202, also listed as-such by IANA. Those are clashing with the code points previously assigned to eFrodoKEM by OQS which we adopted previously.
How should we handle this? I'd probably suggest to just adapt the Frodo code points to whatever OQS uses now (and perhaps mark them as experimental?).
Eep. I guess we will have to do something, since implementations that support these groups, even if we do not, will cause problems for us since we will disagree on what group is in use. I guess if OQS has changed the group IDs to something else already, we should do the same.
(Also I do not understand why IANA is assigning final numbers for drafts, but apparently that’s not a new thing since some other PQ drafts, even withdrawn, have assigned numbers…)
For archeology reasons commit message should mention we had to change the Frodo IDs due to the conflict. Otherwise lgtm
This could cause a merge conflict (or missing adaptions) in conjunction with #4305, because it introduces a new is_pure_ml_kem() in Group_Params. This new method must be considered in the refactorings done there. Also, we are planning to drop support for the round 3 version of Kyber in TLS, which will need modifications in similar locations. @randombit I'll keep my fingers off of the merge button on this PR. Please integrate as you see fit or leave a message if you need my help here.