> My current view is that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024,
> ML-DSA-44, ML-DSA-65, and ML-DSA-87 registered asap
What do you mean by ASAP? Would you like to get a TLS code-points for
algorithms before they are standardised by NIST (hopefully around Q1/24)?
Kind regards,
Kris
Sorry, quick clarification - it’s Panos and myself who prepared, not just me.
(Thanks Panos for your help!)
> On 17 May 2023, at 19:11, Krzysztof Kwiatkowski wrote:
>
> Hi,
>
> Can we get another code point for P256+Kyber768? Following Bas’s draft, I’ve
> prepared si
Hi,
Can we get another code point for P256+Kyber768? Following Bas’s draft, I’ve
prepared similar one:
https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
The goals of having those are:
* Be able to experiment with flows in which FIPS-approved curves are used
* Some HW based
> I would pair secp384r1 with Kyber768 for completely different reasons:
> Kyber768 is what the team kyber recommends.
Agreed.
> I don't think there are very good reasons for NIST curves here outside
> wanting CNSA1 compliance, and for that you need secp384r1 classical
> part. And for that, I
> On 1 Apr 2023, at 09:04, Bas Westerbaan
> wrote:
>
> What about specifying further preliminary key agreements in yet again a
> separate draft?
Agreed. I'll do that.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hello,
Can we add secp256r1_kyber768 option for those who prefer NIST curves?
Kris
> On 29 Mar 2023, at 10:48, Christopher Wood wrote:
>
> As discussed during yesterday's meeting, we would like to assess consensus
> for moving draft-ietf-tls-hybrid-design forward with the following strategy
