I am fine with putting a more inclusive name on the existing range. Russ
> On Mar 28, 2024, at 6:04 PM, David Benjamin <david...@chromium.org> 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 implementations do not need to categorize codepoints they don't > understand. > > The only reason supported groups was partitioned was because of a goofy thing > RFC 7919 did for FFDH. That goofy thing also was what made RFC 7919 > undeployable anyway, so it didn't work out. :-) > > On Thu, Mar 28, 2024 at 5:08 PM Russ Housley <hous...@vigilsec.com > <mailto:hous...@vigilsec.com>> wrote: >> 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 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. >> >> Russ >> >> > On Mar 28, 2024, at 10:52 AM, Sean Turner <s...@sn3rd.com >> > <mailto:s...@sn3rd.com>> wrote: >> > >> > <author hat> >> > >> > **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 Procedures: Specification Required >> > Note: Elliptic curve groups >> > >> > Range 256-511 >> > Registration Procedures: Specification Required >> > Note: Finite Field Diffie-Hellman groups >> > >> > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the >> > path for PQ KEM algorithms (and maybe regardless of whether this is the >> > path), 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”. I have submitted the following >> > issue: >> > https://github.com/tlswg/rfc8447bis/issues/54 >> > and this PR: >> > https://github.com/tlswg/rfc8447bis/pull/55 >> > to address this. >> > >> > spt >> > >> > [1] >> > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 >> > >> > [2] Originally, RFC 8442 defined the name of the registry as "EC Named >> > Curve Registry” and then RFC 7919 re-named it “Supported Groups” and >> > carved out the FFDH space. >> >> _______________________________________________ >> 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
