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

[John Mattsson <[e-mail]>]

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 <[e-mail]> on behalf of Scott Fluhrer (sfluhrer) <sfluhrer=[e-mail]>
Date: Thursday, 11 May 2023 at 16:23
To: Kampanakis, Panos <kpanos=[e-mail]>, Bas Westerbaan <bas=[e-mail]>, Christopher Wood <[e-mail]>
Cc: [e-mail] <[e-mail]>
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 <[e-mail]> On Behalf Of Kampanakis, Panos
Sent: Thursday, May 11, 2023 10:16 AM
To: Bas Westerbaan <bas=[e-mail]>; Christopher Wood <[e-mail]>
Cc: [e-mail]
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Bas Westerbaan
Sent: Wednesday, May 10, 2023 3:09 PM
To: Christopher Wood <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls