On Thu, May 11, 2023 at 02:44:18PM +, Kampanakis, Panos wrote:
> ACK, thx all. So we should refrain from defining such “point-in-time”
> codepoints for other needed long-term algorithm combinations to not
> waste registry space. Only absolutely necessary codepoints should be
> registered.
That
Ping.
From: "Salz, Rich"
Date: Thursday, April 20, 2023 at 3:17 PM
To: "tls@ietf.org"
Subject: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
I’m starting to write the draft about TLS 1.2 being frozen.
It occurred to me that every TLS registry might need a “notes” column. If
someone defi
ACK, thx all. So we should refrain from defining such “point-in-time”
codepoints for other needed long-term algorithm combinations to not waste
registry space. Only absolutely necessary codepoints should be registered.
From: Bas Westerbaan
Sent: Thursday, May 11, 2023 10:39 AM
To: Kampanakis, P
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
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:
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
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 approve
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,
