IANA assigned codepoints for draft-connolly-tls-mlkem-key-agreement

[ghen2]

IANA has assigned codepoints for the standalone MLKEM key exchanges, different from the ones originally requested in draft-connolly-tls-mlkem-key-agreement: (see dconnolly/draft-connolly-tls-mlkem-key-agreement@f008481)

• 0x0105 "MLKEM512"
• 0x0106 "MLKEM768"
• 0x0107 "MLKEM1024"

This also raises a question about the naming of (standardized) algorithms:
Do you want to update the names as algorithms get standardized? Or try to keep them more or less mutually consistent? (not currently the case, eg. "SecP256r1MLKEM768" vs. "p256_mlkem512") Or foresee some form of aliasing to allow for multiple names?

[baentsch]

Thanks for the heads-up @ghen2 !

Do you want to update the names as algorithms get standardized?

That's my intention (and already implemented for the first two hybrid KEMs). Consistency within oqsprovider is nice, but isn't it more desirable for users to be able to use the standardized names across different implementations?

Or foresee some form of aliasing to allow for multiple names?

Not really: If I'm not totally mistaken (need to check again, though), when registering an algorithm via the OpenSSL provider interface, one name must be set; doing multiple registrations of the same algorithm under different names might wreak havoc on the logic -- so I wouldn't want to try that if there's not a really good reason...

[ghen2]

OpenSSL itself allows multiple names for an algorithm, eg. prime256v1 can also be selected as P-256 or secp256r1.
But maybe the provider interface doesn't allow that, I don't know.

I wanted to send a PR to add the 3 new standalone ML-KEM variants, but generate.sh with my version of clang-format (18.1) reformatted a lot of (unrelated) files differently, so I'll let you do it. :)

[danvangeest]

The provider interface allows multiple names for an algorith, and OpenSSL itself does this for it algorithms.

See OSSL_ALGORITHM.algorithm_names in https://docs.openssl.org/3.0/man3/OSSL_ALGORITHM/

In addition to creating aliases for algorithms, it's also useful for loading algorithms by OID string, which may be something for oqs-provider to consider.

[SWilson4]

OpenSSL itself allows multiple names for an algorithm, eg. prime256v1 can also be selected as P-256 or secp256r1. But maybe the provider interface doesn't allow that, I don't know.

I wanted to send a PR to add the 3 new standalone ML-KEM variants, but generate.sh with my version of clang-format (18.1) reformatted a lot of (unrelated) files differently, so I'll let you do it. :)

FYI, we do have a convenience script that does the formatting in a Docker container using the same version of clang-format that we use in CI: see here. Perhaps we need to "surface" this documentation more clearly?

[baentsch]

Perhaps we need to "surface" this documentation more clearly?

I personally find https://github.com/open-quantum-safe/oqs-provider/blob/main/CONTRIBUTING.md#coding-style rather clear... What's your take @ghen2 ? The one thing to further improve the ease of getting a PR through CI is a script locally mimicking all baseline tests. But that raises the question which platforms this script should work on -- albeit, if docker-based, shouldn't be that hard. As usual, PRs welcome!

[ghen2]

Hi

That documentation refers to ./scripts/do_code_format.sh, which invokes clang-format locally. I have clang 18, and this script produced many non-significant diffs (whitespace and line wrapping changes).

There is no mention of a Docker container in CONTRIBUTING.md. Which version of clang are you using there?

[baentsch]

Yikes. I was thinking of format_code.sh, not the older do_code_format.sh. Time to update that reference.

[ghen2]

As it has been noted that those codepoints fall in the range reserved for FFDHE, IANA has reassigned the MLKEM codepoints:

• 0x0200 "MLKEM512"
• 0x0201 "MLKEM768"
• 0x0202 "MLKEM1024"

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

[baentsch]

Thanks for the pointer @ghen2 . I think this time I wait some days for this to settle before changing it here and in the new openssl code base :)

Tagging @tomato42 for her opinion as to whether/when it's sensible/safe to implement/use these code points.

Also tagging @dstebila : The now assigned code points are the ones you had assigned to FrodoKEM in 2019. This obviously has to change as and when this gets implemented: Without statement to the opposite, I'll move FrodoKEM to the "Reserved for private use" area (65024-65279) when implementing this (now re-opened) issue.

[beldmit]

Are there any reasons to place any codepoints non-standardized by IANA out of the "Reserved for private use" range?

[dstebila]

Also tagging @dstebila : The now assigned code points are the ones you had assigned to FrodoKEM in 2019. This obviously has to change as and when this gets implemented: Without statement to the opposite, I'll move FrodoKEM to the "Reserved for private use" area (65024-65279) when implementing this (now re-opened) issue.

That's fine, thanks.

[baentsch]

Are there any reasons to place any codepoints non-standardized by IANA out of the "Reserved for private use" range?

I don't know any. This is logic (and IDs) inherited by oqsprovider from the old openssl fork that the OQS project (initially) didn't want to break interop/compatibility with.

Created #561 to track improving this more generally (best automatically).

[tomato42]

Thanks for the pointer @ghen2 . I think this time I wait some days for this to settle before changing it here and in the new openssl code base :)

Tagging @tomato42 for her opinion as to whether/when it's sensible/safe to implement/use these code points.

Also tagging @dstebila : The now assigned code points are the ones you had assigned to FrodoKEM in 2019. This obviously has to change as and when this gets implemented: Without statement to the opposite, I'll move FrodoKEM to the "Reserved for private use" area (65024-65279) when implementing this (now re-opened) issue.

In general I'm not a fan of the pure KEMs for TLS at all, so I'd say that we shouldn't define them at all.
But with the exception of that, I don't have any technical issues to point to in the draft (it's well written) or the newly assigned IDs (512, 513, 514 are fine).

And yes, I think that algorithms that don't have at the very least an I-D with the numbers listed should use IDs from the "Reserved for private use" range.

[ghen2]

The 0x200-0x202 codepoints are now confirmed in draft-connolly-tls-mlkem-key-agreement-04.