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

[Kris Kwiatkowski]

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 list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Ilari Liusvaara]

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 seems to be size of kyber public key
plus 64 bytes, and given size of server key share seems to be the size
of kyber ciphertext plus 64 bytes.

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).

So I get that the client share should be 1249 bytes (instead of 1248
bytes) and the server key share should be 1153 bytes (instead of 1152
bytes).

Obviously something is wrong somewhere, but where?




-Ilari

___
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

[Kris Kwiatkowski]

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 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 your draft be a WG document, although some might prefer it.
___
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

[Christopher Wood]

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 your draft be a WG document, although some might prefer it.
 



___
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

[Salz, Rich]

  *   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 your draft be a WG document, although some might prefer it.

___
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

[Krzysztof Kwiatkowski]

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

[Krzysztof Kwiatkowski]

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

[Bas Westerbaan]

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 Kyber.

Best,

 Bas

On Thu, May 11, 2023 at 4:17 PM 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 X25519?
>
>
>
>
>
> *From:* TLS  *On Behalf Of * Bas Westerbaan
> *Sent:* Wednesday, May 10, 2023 3:09 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 outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> 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-parameters
>
>
>
> On Mon, May 1, 2023 at 11:59 AM 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

[John Mattsson]

Agree with Scott. And I think this applies to all NIST PQC code points IETF is 
assigning now. Most of the final standards will change and you cannot have a 
single code point for two different algorithms. Very good that there is a 
comment stating “pre-standards version of Kyber768”.

John

From: 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 “Kyber768 Rounds 3 != The final NIST 
approved version”, we should keep codepoint 0x6399 with its current meaning, 
and allocate a fresh one when NIST does public the Kyber FIPS draft (which is 
likely, but not certainly, what will be the final FIPS 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 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 mailto:tls-boun...@ietf.org>> On Behalf Of Bas 
Westerbaan
Sent: Wednesday, May 10, 2023 3:09 PM
To: Christopher Wood mailto:c...@heapingbits.net>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

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

On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
mailto:c...@heapingbits.net>> 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 
> mailto:c...@heapingbits.net>> 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<mailto: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

[Watson Ladd]

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 X25519?
>

We cannot change the meaning of these codepoints without pain and suffering
and broken connections.

>
>
>
>
> *From:* TLS  *On Behalf Of * Bas Westerbaan
> *Sent:* Wednesday, May 10, 2023 3:09 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 outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> 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-parameters
>
>
>
> On Mon, May 1, 2023 at 11:59 AM 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
>
___
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

[Scott Fluhrer (sfluhrer)]

My opinion: since NIST has announced that “Kyber768 Rounds 3 != The final NIST 
approved version”, we should keep codepoint 0x6399 with its current meaning, 
and allocate a fresh one when NIST does public the Kyber FIPS draft (which is 
likely, but not certainly, what will be the final FIPS 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 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 mailto:tls-boun...@ietf.org>> On Behalf Of Bas 
Westerbaan
Sent: Wednesday, May 10, 2023 3:09 PM
To: Christopher Wood mailto:c...@heapingbits.net>>
Cc: tls@ietf.org<mailto:tls@ietf.org>
Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.

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

On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
mailto:c...@heapingbits.net>> 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 
> mailto:c...@heapingbits.net>> 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<mailto: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

[Kampanakis, Panos]

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, May 10, 2023 3:09 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 outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


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

On Mon, May 1, 2023 at 11:59 AM Christopher Wood 
mailto:c...@heapingbits.net>> 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 
> mailto:c...@heapingbits.net>> 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

[Bas Westerbaan]

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

On Mon, May 1, 2023 at 11:59 AM 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

[Christopher Wood]

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

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

[Hubert Kario]

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




there's a third reason: the public CAs that support ECDSA almost 
exclusively
support just P-256 and P-384, so if somebody implements ECDSA for the 
public

internet, they have to support those two curves at the very least.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
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

[Blumenthal, Uri - 0553 - MITLL]

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 
won’t know the *exact* details of the algorithm. 

However, if people consider experimenting with Kyber deployment now, and want 
to define appropriate MTI now (and want to use Hybrid, aka combined, key 
exchange) - then it’s as pointless now as it will be in the future to define 
P384+Kyber768, because either there won’t be such a Hybrid at all (NSA stated 
that they won’t require Hybrid in products that need their certification) or 
there will be P384+Kyber1024, whatever the latter will look like then. 

Regards,
Uri

> On Apr 2, 2023, at 06:43, Ilari Liusvaara  wrote:
> 
> 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
>> (page 1).
>> 
>> CNSA-2.0 allows only Kyber-1024. Not -768. See 
>> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
>> (page 4).
>> 
>> So, if somebody would insist on a CNSA-compliant hybrid - there is
>> only one candidate from each group to consider for the MTI. 
>> 
>> It also means that MTI für P-384 with Kyber-768 is likely to be quite
>> useless, as those not bound by CNSA would probably make other choices
>> (not P-384)  anyway, and those required to comply with CNSA will have
>> to settle for what I described. 
>> 
>> Did I make it clear enough? Or do you see a hole in my logic?
> 
> I think what "CRYSTALS: Kyber" means in CNSA-2.0 is the final
> specification. Which obviously is not available yet, so it is impossible
> to currently make any key exchange or asymmetric encryption compliant
> with CNSA-2.0.
> 
> As to what sense does publishing CNSA-2.0 before the algorithms are
> known make? Note that it does have algorithms for firmware signing
> fully specified, and urges those to be deployed as soon as possible.
> And I suppose there might be sense timing-wise on publishing a spec
> referencing a future spec that will likely undergo nontrivial draft
> period.
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Ilari Liusvaara]

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
> (page 1).
> 
> CNSA-2.0 allows only Kyber-1024. Not -768. See 
> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF
> (page 4).
>
> So, if somebody would insist on a CNSA-compliant hybrid - there is
> only one candidate from each group to consider for the MTI. 
> 
> It also means that MTI für P-384 with Kyber-768 is likely to be quite
> useless, as those not bound by CNSA would probably make other choices
> (not P-384)  anyway, and those required to comply with CNSA will have
> to settle for what I described. 
> 
> Did I make it clear enough? Or do you see a hole in my logic?

I think what "CRYSTALS: Kyber" means in CNSA-2.0 is the final
specification. Which obviously is not available yet, so it is impossible
to currently make any key exchange or asymmetric encryption compliant
with CNSA-2.0.

As to what sense does publishing CNSA-2.0 before the algorithms are
known make? Note that it does have algorithms for firmware signing
fully specified, and urges those to be deployed as soon as possible.
And I suppose there might be sense timing-wise on publishing a spec
referencing a future spec that will likely undergo nontrivial draft
period.



-Ilari

___
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

[Blumenthal, Uri - 0553 - MITLL]

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/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF 
(page 4).

So, if somebody would insist on a CNSA-compliant hybrid - there is only one 
candidate from each group to consider for the MTI. 

It also means that MTI für P-384 with Kyber-768 is likely to be quite useless, 
as those not bound by CNSA would probably make other choices (not P-384)  
anyway, and those required to comply with CNSA will have to settle for what I 
described. 

Did I make it clear enough? Or do you see a hole in my logic?

Regards,
Uri

> On Apr 1, 2023, at 05:54, Ilari Liusvaara  wrote:
> 
> 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 introduce Kyber768, but you are right, the new draft should
>> include an MTI identifier.
> 
> The problem with having both is that it bifurcates the system. While
> being on wrong side is not a hard failure, it is still rather annoying
> perf hit.
> 
> For clients to support either, servers must support both.
> 
> At least with P-384 hybrid, folks are less likely to deploy the thing
> unless needed.
> 
> 
> 
> -Ilari
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Ilari Liusvaara]

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 introduce Kyber768, but you are right, the new draft should
> include an MTI identifier.

The problem with having both is that it bifurcates the system. While
being on wrong side is not a hard failure, it is still rather annoying
perf hit.

For clients to support either, servers must support both.

At least with P-384 hybrid, folks are less likely to deploy the thing
unless needed.



-Ilari

___
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

[Ilari Liusvaara]

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 RFC7748 instead
> > of RFC8037...
> >
> >
> > Really quick and dirty way to fix this would be to publish editor's
> > copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
> > RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
> > the references.
> >
> 
> Thanks, done. Posted -02 of both the Kyber and Xyber drafts.

Thanks, that addresses my concern. 



-Ilari

___
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

[Krzysztof Kwiatkowski]

> 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

[Krzysztof Kwiatkowski]

> 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

[Kampanakis, Panos]

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, March 31, 2023 8:04 PM
To: Ilari Liusvaara 
Cc: TLS@ietf.org
Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


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 for internal networks. So I do not oppose 
specifying additional preliminary key agreements, but I do not like to actively 
support it. What about specifying further preliminary key agreements in yet 
again a separate draft?

Best,

 Bas

On Sat, Apr 1, 2023 at 1:56 AM Bas Westerbaan 
mailto:b...@cloudflare.com>> 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 RFC7748 instead
of RFC8037...


Really quick and dirty way to fix this would be to publish editor's
copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
the references.

Thanks, done. Posted -02 of both the Kyber and Xyber drafts.

Best,

 Bas

___
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

[Bas Westerbaan]

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 for internal networks. So I do not
oppose specifying additional preliminary key agreements, but I do not like
to actively support it. What about specifying further preliminary key
agreements in yet again a separate draft?

Best,

 Bas

On Sat, Apr 1, 2023 at 1:56 AM 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 RFC7748 instead
>> of RFC8037...
>>
>>
>> Really quick and dirty way to fix this would be to publish editor's
>> copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
>> RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
>> the references.
>>
>
> Thanks, done. Posted -02 of both the Kyber and Xyber drafts.
>
> Best,
>
>  Bas
>
>
___
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

[Bas Westerbaan]

>
> 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 this would be to publish editor's
> copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
> RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
> the references.
>

Thanks, done. Posted -02 of both the Kyber and Xyber drafts.

Best,

 Bas
___
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

[Ilari Liusvaara]

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, 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_kyber768
> > combines two equivalent security levels.

Is that the case? Secp384r1 is 192-level DH, but Kyber768 is quoted to
be Category III (and I think it is not significantly above Category III
requirements), which is defined as equivalent to 192-level encryption.
192-level DH is stronger than 192-bit encryption.

(Another illustration of numbers not being comparable is that Category
IV is defined as equivalent to 192-level hash.)

I would pair secp384r1 with Kyber768 for completely different reasons:
Kyber768 is what the team kyber recommends.


> > From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
> > Sent: Tuesday, March 28, 2023 10:40 PM
> > To: Krzysztof Kwiatkowski ; Christopher Wood 
> > 
> > Cc: TLS@ietf.org
> > Subject: RE: [EXTERNAL][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

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.




-Ilari

___
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

[Ilari Liusvaara]

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 codepoints from draft-ietf-tls-hybrid-design and advance
>this document through the process towards publication.

Support.


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

I have a concern with this:

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 this would be to publish editor's
copy as draft-cfrg-schwabe-kyber-02 (or if CFRG adapts quickly, the
RG-00), and then publish draft-tls-westerbaan-xyber768d00-01, fixing
the references.




-Ilari

___
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

[Blumenthal, Uri - 0553 - MITLL]

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_kyber768 combines two equivalent 
> security levels.
> Those that want to be extra conservative can go secp521r1_kyber1024 which 
> won’t be much worse than secp384r1_kyber1024 in performance or size.
>  
>  
>  
> From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
> Sent: Tuesday, March 28, 2023 10:40 PM
> To: Krzysztof Kwiatkowski ; 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 outside of the organization. Do not click 
> links or open attachments unless you can confirm the sender and know the 
> content is safe.
> 
>  
> Can we add secp256r1_kyber768 option for those who prefer NIST curves?
>  
> I support this.
>  
> I would also like secp384r1_kyber1024 option, please.
>  
> Thanks


smime.p7s
Description: S/MIME cryptographic signature
___
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

[Loganaden Velvindron]

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

[Kampanakis, Panos]

> 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’t 
be much worse than secp384r1_kyber1024 in performance or size.



From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Tuesday, March 28, 2023 10:40 PM
To: Krzysztof Kwiatkowski ; 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 outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Can we add secp256r1_kyber768 option for those who prefer NIST curves?

I support this.

I would also like secp384r1_kyber1024 option, please.

Thanks
___
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

[Kampanakis, Panos]

+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 outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hello,

Can we add secp256r1_kyber768 option for those who prefer NIST curves?

Kris



On 29 Mar 2023, at 10:48, Christopher Wood 
mailto:c...@heapingbits.net>> 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

[Blumenthal, Uri - 0553 - MITLL]

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

 



smime.p7s
Description: S/MIME cryptographic signature
___
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

[Salz, Rich]

> 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

[Richard Barnes]

+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 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
>
___
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

[Christopher Patton]

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

[Eric Rescorla]

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

[Krzysztof Kwiatkowski]

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