New "permanent temporary" P256+Kyber768 IANA codepoint support in OQS OpenSSH

[csosto-pk]

Hi folks,

There has been consensus for TLS to combine classical ECDH with Kyber-768 (not 512). The reason is the Kyber-512's security level is considered less than 128-bits and those that want to be conservative chose Kyber768 as the default. Drafts draft-tls-westerbaan-xyber768d00 and draft-kwiatkowski-tls-ecdhe-kyber got assigned temporary codepoints for ECDH with Kyber768 combinations. These are supported in OQS OpenSSL already I believe.

I think this can be the sane strategy for a temporary IANA codepoint for SSH on top of the temporary, "arbitrary" ones in draft-kampanakis-curdle-ssh-pq-ke we are all have coded to.

So, after we have the first draft spec of Kyber768, we would like to add support for P256-Kyber768 by using a "permanent temporary" IANA registry codepoint. This codepoint can live forever until we get the final final spec. At that point we will not need the codepoint any more, but it can still be supported until everyone migrates. This is the approach TLS is taking as well.

We would like to have OQS OpenSSH support this codepoint as the defacto PQ OpenSSH library. Otherwise there is no reason to support it on our own.

Any interest in adding support for a "temporary permanent" P256+Kyber768 codepoint?

[dstebila]

I don't understand the exact meaning of "temporary permanent" codepoint, but overall yes fine with me to do a P256+Kyber768 (or X25519+Kyber768) in SSH. We might have to do a little bit of extra work on our code generation templates to generate that combination, but it makes sense to do so.

[csosto-pk]

"Temporary permanent" sounds like an oxymoron indeed, but it is basically what draft-tls-westerbaan-xyber768d00 and draft-kwiatkowski-tls-ecdhe-kyber did for TLS 1.3. They provided an IANA registry codepoint we can all use. So far we all have been using the OQS codepoints which is fine, but an IANA codepoint is set in stone, there can't be any conflicts about it and it lives in eternity. But it is also temporary practically because we know that when it is final, we will get the "final" codepoint assigned by draft-ietf-tls-hybrid-design.

[anhu]

Yes, I'm good with the idea of this. Perhaps another name like "interim" might be nicer?

[csosto-pk]

An update on the plan:

draft-yee-ssh-iana-requirements is not ratified yet. We can't get an IANA codepoint until it is an RFC. Given that time is passing and we will have the final ML-KEM spec mid-2024, it does not make sense to get a codepoint now, and then another one for ML-KEM in less than a year.

So, here is what we can do: Close to the summer of 2024, after we have the stable, almost final NIST FIPS 203 and after draft-yee-ssh-iana-requirements is ratified, we will write a new draft draft-curdle-pq-mlkem-ssh which will define three new IANA codepoints

• x25519-mlkem768-sha256
• p256-mlkem768-sha256
• p384-mlkem1024-sha384

That should give us all the codepoints we need with the final ML-KEM.

Then OQS OpenSSH, our implementation, wolfSSH, and OpenSSH can implement any of these method names that make sense to them. OpenSSH indicated that they would like to support x25519-mlkem768-sha256 if they find time to implement.

[baentsch]

OpenSSH indicated that they would like to support x25519-mlkem768-sha256 if they find time to implement.

May I ask then which value is still seen in retaining this fork? Wouldn't it be more reasonable to consider supporting the upstream interest instead and sunsetting this as an OQS subproject?

[dstebila]

OpenSSH indicated that they would like to support x25519-mlkem768-sha256 if they find time to implement.

May I ask then which value is still seen in retaining this fork? Wouldn't it be more reasonable to consider supporting the upstream interest instead and sunsetting this as an OQS subproject?

In the long run we do want to see the standardized algorithms adopted in base OpenSSH, so we wouldn't fit that need once they've done so. There could be a role for experimenting with the remaining round 4 algorithms or the signature on ramp, as we start to add new signature algorithms to the experimental branch.

[csosto-pk]

In the long run we do want to see the standardized algorithms adopted in base OpenSSH, so we wouldn't fit that need once they've done so. There could be a role for experimenting with the remaining round 4 algorithms or the signature on ramp, as we start to add new signature algorithms to the experimental branch.

I agree. Also, I am not sure OpenSSH is considering to support more than x25519-mlkem768-sha256 at this point. Even that may take some time...

[geedo0]

@csosto-pk, can we close this issue in favor of Issue #163? I plan on adding support for mlkem768nistp256-sha256 and mlkem1024nistp384-sha384 there. I also plan on looking into the implementation effort for x25519-mlkem768-sha256.