Proposal Details
For Go 1.27, we should implement MLKEM1024 from draft-ietf-tls-mlkem-07.
It is the only key exchange in the CNSA 2.0 profile and with the CRQC timelines getting more aggressive, it is safer than X25519 or secp256r1, and only marginally less safe than X25519MLKEM768 and SecP256r1MLKEM768.
Its specification is nominally still a draft, but IANA assigned the codepoint based on the equivalent draft-connolly-tls-mlkem-key-agreement-05, and Chrome already implemented it. There is no chance it will change.
For now, there is no reason to enable it by default. Systems that need CNSA 2.0 compliance can enable it as needed. This might change in the future if CNSA 2.0 systems become common on the open internet.
In terms of exposed API, it involves only a const MLKEM1024 CurveID = 514.
There is no need for a GODEBUG, since it is not enabled by default.
/cc @golang/security
Proposal Details
For Go 1.27, we should implement MLKEM1024 from draft-ietf-tls-mlkem-07.
It is the only key exchange in the CNSA 2.0 profile and with the CRQC timelines getting more aggressive, it is safer than X25519 or secp256r1, and only marginally less safe than X25519MLKEM768 and SecP256r1MLKEM768.
Its specification is nominally still a draft, but IANA assigned the codepoint based on the equivalent draft-connolly-tls-mlkem-key-agreement-05, and Chrome already implemented it. There is no chance it will change.
For now, there is no reason to enable it by default. Systems that need CNSA 2.0 compliance can enable it as needed. This might change in the future if CNSA 2.0 systems become common on the open internet.
In terms of exposed API, it involves only a
const MLKEM1024 CurveID = 514.There is no need for a GODEBUG, since it is not enabled by default.
/cc @golang/security