PQC: Add TLS 1.3 groups for (pure) ML-KEM-512, -768 and -1024

[reneme]

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).

[coveralls]

coverage: 91.132% (-0.01%) from 91.146%
when pulling c98372a on Rohde-Schwarz:tls/ml_kem
into 087f6ca on randombit:master.

[randombit]

Seems ok to support pure PQ I guess (but can anyone really not spare the extra 32 bytes for a X25519 or P-256 kex, idk…) but I’d lean towards deferring this to 3.7.0 just to avoid too much proliferation of draft TLS suites.

Especially what I’d be concerned with is, clearly this draft is still in flux. If something changes incompatibly in a future draft but using the same cutesy suite ids, we can either support the old draft (remaining compatible with ourselves, but incompatible with other impls) or support the new draft (and then break our ability to talk cross versions).

Already I’m trying to figure out if we can get away with dropping the Kyber r3 suites without too much disruption… I guess I did something similar with the Newhope suites back in the day and nobody complained.

[reneme]

(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);
    });