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