Re: [TLS] What is the TLS WG plan for quantum-resistant algorithms?
> 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
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 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 solutions simply don’t have X25519, adding it to resource > constrained devices > is kind of problematic and reusing ECDHE/P-256 already provided in HW seems > to simplify > migration. > > Kind regards, > Kris > >> On 1 May 2023, at 10:58, Christopher Wood wrote: >> >> It looks like we have consensus for this strategy. We’ll work to remove >> codepoints from draft-ietf-tls-hybrid-design and then get experimental >> codepoints allocated based on draft-tls-westerbaan-xyber768d00. >> >> Best, >> Chris, for the chairs >> >>> On Mar 28, 2023, at 9:49 PM, 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 >>> for allocating codepoints we can use in deployments. >>> >>> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this >>> document through the process towards publication. >>> 2. Write a simple -00 draft that specifies the target variant of >>> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully >>> did this for us already [1].) Once this is complete, request a codepoint >>> from IANA using the standard procedure. >>> >>> The intent of this proposal is to get us a codepoint that we can deploy >>> today without putting a "draft codepoint" in an eventual RFC. >>> >>> Please let us know if you support this proposal by April 18, 2023. Assuming >>> there is rough consensus, we will move forward with this proposal. >>> >>> Best, >>> Chris, Joe, and Sean >>> >>> [1] >>> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00 >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
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 solutions simply don’t have X25519, adding it to resource constrained devices is kind of problematic and reusing ECDHE/P-256 already provided in HW seems to simplify migration. Kind regards, Kris > On 1 May 2023, at 10:58, Christopher Wood wrote: > > It looks like we have consensus for this strategy. We’ll work to remove > codepoints from draft-ietf-tls-hybrid-design and then get experimental > codepoints allocated based on draft-tls-westerbaan-xyber768d00. > > Best, > Chris, for the chairs > >> On Mar 28, 2023, at 9:49 PM, 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 >> for allocating codepoints we can use in deployments. >> >> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this >> document through the process towards publication. >> 2. Write a simple -00 draft that specifies the target variant of >> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully >> did this for us already [1].) Once this is complete, request a codepoint >> from IANA using the standard procedure. >> >> The intent of this proposal is to get us a codepoint that we can deploy >> today without putting a "draft codepoint" in an eventual RFC. >> >> Please let us know if you support this proposal by April 18, 2023. Assuming >> there is rough consensus, we will move forward with this proposal. >> >> Best, >> Chris, Joe, and Sean >> >> [1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00 > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
> 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 would pick secp384r1_kyber768. > >From my perspective, the two reasons for including a NIST curves are: 1. To have an option for those who require FIPS compliance. In a short term at least one key agreement scheme should be FIPS-approved. In the long term both of them should be fips-approved. That way, in case security of Kyber768 falls below 112-bits or simply implementation is broken, one can still run key agreement in FIPS compliant manner. In the end, the ultimate goal of hybrid-tls draft is to ensure that at least one of the schemes provides security if the other gets broken. Would be good to use this in FIPS context also. 2. NIST curves are more often implemented in HW than Curve25519. When working with chips like ATECC608B, one ideally only adds SW-based Kyber and can reuse existing HW-based ECDH. Such migration is simpler, less risky and time-consuming than adding SW-based X25519. To accelerate migration, the hybrid-tls draft should move forward rather quickly and be useful variety of use-cases. Hence, I suggest we assign two codepoints one for X25519-Kyber768 and the other for ECDH/p256-Kyber768. X25519 and P256 provide same security level, from my old days in Cloudflare I remember both schemes were used quite often in TLS, so I hope this choice is not to controversial. Regarding CNSA, I've no experience with national security systems, but does it actually allows to use hybrid schemes? it seems to me that neither 1.0 nor 2.0 allows usage of hybrid schemes (SP800-56C is mentioned but in regards to ECDH, not KDF). Maybe those needs can be addressed at later stage? Kind regards, --- Kris Kwiatkowski Staff Cryptography Architect PQShield ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
> 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
Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design
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 > for allocating codepoints we can use in deployments. > > 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this > document through the process towards publication. > 2. Write a simple -00 draft that specifies the target variant of > X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did > this for us already [1].) Once this is complete, request a codepoint from > IANA using the standard procedure. > > The intent of this proposal is to get us a codepoint that we can deploy today > without putting a "draft codepoint" in an eventual RFC. > > Please let us know if you support this proposal by April 18, 2023. Assuming > there is rough consensus, we will move forward with this proposal. > > Best, > Chris, Joe, and Sean > > [1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00 > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
