Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

[Russ Housley <[e-mail]>]

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 <[e-mail]> 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.