Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

However, the difference is stated to be UncompressedPointRepresentation for P256 from TLS 1.3. AFACIT, that is 65 bytes (1 legacy_form byte, 32 bytes for x, 32 bytes for y). Right, one byte for the legacy_form is missing. Let me fix it.___ TLS mailing

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Fri, May 19, 2023 at 06:57:09PM +0100, Kris Kwiatkowski wrote: > Hello, > > The codepoint for P-256+Kyber768 has been just assigned by IANA. The value > is 0x639A. > Thanks Rich for pointing to the request form. I get off-by-one for the sizes of key shares. The given size of client key share

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Hello, The codepoint for P-256+Kyber768 has been just assigned by IANA. The value is 0x639A. Thanks Rich for pointing to the request form. Kind regards, Kris On 18/05/2023 22:00, Christopher Wood wrote: Thanks, Rich! On May 17, 2023, at 3:44 PM, Salz, Rich wrote:  * Can we get anothe

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Thanks, Rich!On May 17, 2023, at 3:44 PM, Salz, Rich wrote: Can we get another code point for P256+Kyber768?   Fill out the form at https://www.iana.org/form/protocol-assignment  Or send email to tls-reg-rev...@iana.org and copy iana-prot-pa...@iana.org  There is no requirement that you

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

* Can we get another code point for P256+Kyber768? Fill out the form at https://www.iana.org/form/protocol-assignment Or send email to tls-reg-rev...@iana.org and copy iana-prot-pa...@iana.org There is no requirement that yo

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://datatr

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 sol

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Hi Panos, No, for the final version of Kyber we'd need a different code point. (And that one will presumably be defined in Douglas' hybrid I-D.) The raison d'être of draft-schwabe-cfrg-kyber-02 and draft-westerbaan-tls-xyber768d00 is to have a stable reference for this preliminary version of Kybe

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

: TLS on behalf of Scott Fluhrer (sfluhrer) Date: Thursday, 11 May 2023 at 16:23 To: Kampanakis, Panos , Bas Westerbaan , Christopher Wood Cc: tls@ietf.org Subject: Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design My opinion: since NIST has announced that

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Thu, May 11, 2023, 7:17 AM Kampanakis, Panos wrote: > Great! > > So to clarify, when Kyber gets ratified as MLWE_KEM or something like > that, will we still be using 0x6399 in the keyshare when we are > negotiating? Or is 0x6399 just a temporary codepoint for Kyber768 Round 3 > combined with

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

approved version…) From: TLS On Behalf Of Kampanakis, Panos Sent: Thursday, May 11, 2023 10:16 AM To: Bas Westerbaan ; Christopher Wood Cc: tls@ietf.org Subject: Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design Great! So to clarify, when Kyber gets ratified as

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Great! So to clarify, when Kyber gets ratified as MLWE_KEM or something like that, will we still be using 0x6399 in the keyshare when we are negotiating? Or is 0x6399 just a temporary codepoint for Kyber768 Round 3 combined with X25519? From: TLS On Behalf Of Bas Westerbaan Sent: Wednesday,

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

FYI IANA has added the following entry to the TLS Supported Groups registry: Value: 25497 Description: X25519Kyber768Draft00 DTLS-OK: Y Recommended: N Reference: [draft-tls-westerbaan-xyber768d00-02] Comment: Pre-standards version of Kyber768 Please see https://www.iana.org/assignments/tls-parame

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

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: >

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Saturday, 1 April 2023 03:50:04 CEST, Krzysztof Kwiatkowski wrote: 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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

That is correct - CNSA-2.0 prescribes the “NIST Kyber”, whatever changes this may include to the Kyber-1024, aka Kyber at NIST Sec Level V. One can speculate about what changes would be proposed during the public comments period, and which of them would be accepted. Regardless, until then we w

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Sun, Apr 02, 2023 at 02:54:57AM +, Blumenthal, Uri - 0553 - MITLL wrote: > CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B > that also permitted P-256. P-521 is not included either. See > https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF > (pa

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B that also permitted P-256. P-521 is not included either. See https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF (page 1). CNSA-2.0 allows only Kyber-1024. Not -768. See https://media.defense.gov/20

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Sat, Apr 01, 2023 at 02:12:14AM +, Kampanakis, Panos wrote: > Hi Bas, > > I prefer for the MTI to be P-256+Kyber768 for compliance reasons. Uh, I think this thing is too experimental to have any MTI. > It would be trivial for servers to add support for both identifiers > as they introduc

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Sat, Apr 01, 2023 at 01:56:23AM +0200, Bas Westerbaan wrote: > > > > The draft draft-tls-westerbaan-xyber768d00-00 references > > draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes, > > since fixed in editor's copy. > > > > And then, the correct reference for X25519 is probably

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 woul

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

Hi Bas, I prefer for the MTI to be P-256+Kyber768 for compliance reasons. It would be trivial for servers to add support for both identifiers as they introduce Kyber768, but you are right, the new draft should include an MTI identifier. From: TLS On Behalf Of Bas Westerbaan Sent: Friday, Mar

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Regarding additional key agreements. For the (public) web it would be best if we can agree on a default key agreement. If one half uses P-256+Kyber768 and the other X25519+Kyber768, then clients will either HRR half the time or need to send both. Neither are ideal. Obviously this point is moot fo

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

> > The draft draft-tls-westerbaan-xyber768d00-00 references > draft-cfrg-schwabe-kyber-01, which has a number of annoying mistakes, > since fixed in editor's copy. > > And then, the correct reference for X25519 is probably RFC7748 instead > of RFC8037... > > > Really quick and dirty way to fix thi

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Wed, Mar 29, 2023 at 02:59:51PM +, Blumenthal, Uri - 0553 - MITLL wrote: > Because that’s what CNSA requires. I don't think that is the case. CNSA1 does not consider the Kyber part, and CNSA2 requires something that is not currently available. > > On Mar 29, 2023, at 00:45, Kampanakis,

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

On Wed, Mar 29, 2023 at 10:48:32AM +0900, 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 codepo

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Because that’s what CNSA requires. Regards, Uri > On Mar 29, 2023, at 00:45, Kampanakis, Panos wrote: > >  > > > I would also like secp384r1_kyber1024 option, please. > > Why do you up the ECDH curve sec level with Kyber1024? It adds unnecessary > size to the keyshare. like secp384r1_kyb

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

I hope this moves forward. On Wed, 29 Mar 2023 at 05:50, 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. >

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

> I would also like secp384r1_kyber1024 option, please. Why do you up the ECDH curve sec level with Kyber1024? It adds unnecessary size to the keyshare. like secp384r1_kyber768 combines two equivalent security levels. Those that want to be extra conservative can go secp521r1_kyber1024 which won

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

+1 for NIST curve codepoints. From: TLS On Behalf Of Krzysztof Kwiatkowski Sent: Tuesday, March 28, 2023 10:00 PM To: Christopher Wood Cc: TLS@ietf.org Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design CAUTION: This email originated from outsi

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Can we add secp256r1_kyber768 option for those who prefer NIST curves? I support this. I would also like secp384r1_kyber1024 option, please. Thanks On 29 Mar 2023, at 10:48, Christopher Wood wrote: As discussed during yesterday's meeting, we would like to assess consensus for

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

> 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. I support the proposal ___ 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

+1 On Tue, Mar 28, 2023 at 10:15 PM Christopher Patton wrote: > I support this. Adding P256 + Kyber768 seems like a good idea. > > Chris P. > > On Wed, Mar 29, 2023 at 10:50 AM Christopher Wood > wrote: > >> As discussed during yesterday's meeting, we would like to assess >> consensus for movin

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

I support this. Adding P256 + Kyber768 seems like a good idea. Chris P. On Wed, Mar 29, 2023 at 10:50 AM 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 alloc

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

I support this proposal. On Tue, Mar 28, 2023 at 6: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. > >

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