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

+1 to removing the "Elliptic curve groups" note. That partition came out of
RFC 7919's (unfortunate
<https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/>)
decision to repurpose the existing DHE cipher suites (see RFC 7919, section
4), so we're stuck treating 256-511 as special. But I don't believe we need
to treat the remainder as special.

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 met with confusion about what in the world a "group" is, and I've
had to embarrassingly explain that yes, it is a term of art, short for
"Diffie-Hellman group", no, it doesn't even make sense with PQC, and I'm
truly very sorry that TLS chose such a needlessly confusing name, but it's
the name we've got. Sometimes I just give up on the TLSWG's naming and just
saying "key exchange" or "key agreement", but that gets a little tricky
because that can also mean the left half of a TLS 1.2 cipher suite
(ECDHE_RSA / ECDHE_ECDSA / RSA). At one point, we tried "key exchange
group" to avoid that, but that's also problematic as one needs to explain
to translators that this does not mean "primary trade collection".

This name is bad enough that I needed to make a pre-written explanation for
this, so I can save time and link to it every time it comes up.

At the same time, we've already renamed this once. These names we pick make
their way everywhere, each rename we do is costly. All the old "curve" APIs
had to be doubled up and deprecated in systems, with the old ones forever
stuck around. And then some systems (probably correctly) decided to stick
with the old "curve" name. Renaming again will add a third, and repeat this
costly cycle.

Had we not renamed, I would say we just keep it at "curves". While "curves"
is also wrong for PQC, it is less generic of a name than "group" and, in my
experience, reads more clearly as a random term of art. It's a pity that we
then changed it to one of the most overloaded words in English imaginable.
:-(

David

On Thu, Mar 28, 2024 at 11:32 AM John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
>
>
> It would actually be 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 <tls-bounces@ietf.org> on behalf of Sean Turner <
> sean@sn3rd.com>
> *Date: *Thursday, 28 March 2024 at 15:53
> *To: *TLS List <tls@ietf.org>
> *Subject: *[TLS] -draft8447bis: rename Support Group Elliptic curve
> groups space
>
> <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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fissues%2F54&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825594155%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FKpJyM8%2BPLS7Wd1zNGlZoqhFFEQuLNNRzY8bsUQxegA%3D&reserved=0
> <https://github.com/tlswg/rfc8447bis/issues/54>
> and this PR:
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F55&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825602619%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=nMQWHlYdoSNn9yNstiB2wNLQw5IZl%2BfHtf14UvOInd8%3D&reserved=0
> <https://github.com/tlswg/rfc8447bis/pull/55>
> to address this.
>
> spt
>
> [1]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Ftls-parameters%2Ftls-parameters.xhtml%23tls-parameters-8&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825608404%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=f3oRbu1I2ThwoKYyK%2BlyO1SDPOrsc3mXShCT%2BeBM3ls%3D&reserved=0
> <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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0a5a0e0174b640b9535508dc4f36c377%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638472343825613044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EPub%2F4QhJkK3loRgrjTRvpvJ%2FHD7V2qMujI%2FUQW5HAo%3D&reserved=0
> <https://www.ietf.org/mailman/listinfo/tls>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>