Guilin
Wang Guilin
Mobile: +65-86920345
Email: wang.gui...@huawei.com
From:Deirdre Connolly
mailto:durumcrustu...@gmail.com>>
To:Russ Housley mailto:hous...@vigilsec.com>>
Cc:IETF TLS mailto:tls@ietf.org>>
Date:2024-03-30 04:43:30
Subject:Re: [TLS] -draft8447bis: rename Supp
To me, it looks like we have rough agreement to change the note as specified in
the PR.
spt
> On Mar 28, 2024, at 10:52, Sean Turner wrote:
>
>
>
> **WARNING: Potential bikeshed**
>
> -connolly-tls-mlkem-key-agreement has suggested that code points for the NIST
> PQ be registered in the
On Fri, Mar 29, 2024 at 1:42 PM Deirdre Connolly
wrote:
> > KEMs are not "key agreement" algorithms as suggested by this draft
> name. In a key agreement algorithm, both parties contribute to the shared
> secret. With a KEM, only one party generates the the shared secreat value.
>
> This is
> KEMs are not "key agreement" algorithms as suggested by this draft name.
In a key agreement algorithm, both parties contribute to the shared
secret. With a KEM, only one party generates the the shared secreat value.
This is not generally accurate with the KEM schemes under consideration for
I am fine with putting a more inclusive name on the existing range.
Russ
> On Mar 28, 2024, at 6:04 PM, David Benjamin wrote:
>
> I don't believe we need a separate range, just to unmark the elliptic curve
> range. TLS does not usually ascribe meaning to ranges of codepoints because
> TLS
On Fri, Mar 29, 2024 at 2:59 AM David Benjamin wrote:
> Regarding renaming, I'm torn. "Group" was a truly horrible rename. The names
> we pick make their way into APIs and even sometimes UI surfaces for
> developers. Every time I've plumbed TLS named groups into another system,
> I've been
I don't believe we need a separate range, just to unmark the elliptic
curve range. TLS does not usually ascribe meaning to ranges of codepoints
because TLS implementations do not need to categorize codepoints they don't
understand.
The only reason supported groups was partitioned was because of a
Sean:
I observe that ML-KEM is not a Elliptic curve group or a Finite Field
Diffie-Hellman group. I really think we want to include sepport for KEMs. but
a separate range is needed. I assume it will be carved out of the Elliptic
curve group range.
KEMs are not "key agreement" algorithms as
Clarification: I agree on the need to rename the group space. However, I
don't support using only mlkem as a curve for tls. However, mlkem as a
hybrid makes sense.
On Thu, Mar 28, 2024, 20:28 Loganaden Velvindron
wrote:
> Agreed.
>
> On Thu, Mar 28, 2024, 19:50 Salz, Rich
> wrote:
>
>> > we
Agreed.
On Thu, Mar 28, 2024, 19:50 Salz, Rich
wrote:
> > we should really replace the “Elliptic curve groups” note in the 0-255,
> 512-65535 range row with something else. I am open to suggestions, but
> would like to propose “unallocated”.
>
> Short and to the point; +1
>
> The only
good to change the name of the registry from
> “Supported Groups” as the new PQC key exchange algorithms are not groups.
>
>
>
> Cheers,
>
> John Preuß Mattsson
>
>
>
> *From: *TLS on behalf of Sean Turner <
> s...@sn3rd.com>
> *Date: *Thursday, 28 March 202
> we should really replace the “Elliptic curve groups” note in the 0-255,
> 512-65535 range row with something else. I am open to suggestions, but would
> like to propose “unallocated”.
Short and to the point; +1
The only alternative I can see is constantly adding things, and eventually we
: rename Support Group Elliptic curve groups space
**WARNING: Potential bikeshed**
-connolly-tls-mlkem-key-agreement has suggested that code points for the NIST
PQ be registered in the TLS Supported Groups IANA registry [1]. Currently [2],
the registry is carved up into three blocks as follows
**WARNING: Potential bikeshed**
-connolly-tls-mlkem-key-agreement has suggested that code points for the NIST
PQ be registered in the TLS Supported Groups IANA registry [1]. Currently [2],
the registry is carved up into three blocks as follows:
Range: 0-255, 512-65535
Registration
14 matches
Mail list logo
