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

[Sean Turner]

**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

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

[John Mattsson]

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  on behalf of Sean Turner 
Date: Thursday, 28 March 2024 at 15:53
To: TLS List 
Subject: [TLS] -draft8447bis: 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:

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

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

[Salz, Rich]

> 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 
get to "curves and lattices and heffalumps oh me..."


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[David Benjamin]

+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  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  on behalf of Sean Turner <
> s...@sn3rd.com>
> *Date: *Thursday, 28 March 2024 at 15:53
> *To: *TLS List 
> *Subject: *[TLS] -draft8447bis: 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:
>
> 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%2Fa

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

[Loganaden Velvindron]

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 alternative I can see is constantly adding things, and eventually
> we get to "curves and lattices and heffalumps oh me..."
>
>
> ___
> 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

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

[Loganaden Velvindron]

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 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 get to "curves and lattices and heffalumps oh me..."
>>
>>
>> ___
>> 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

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

[Russ Housley]

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  wrote:
> 
> 
> 
> **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

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

[David Benjamin]

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  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  wrote:
> >
> > 
> >
> > **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

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

[Bob Beck]

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 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.

This would be why in spite of the fact that I dislike the "group"
name, I would lean more to the "no do not rename" - We already deal
with "group" and "curve" for this and the names are scattered through
API and implementations, and we already have to deal with explaining
it's not really a group, and not really a curve, and it was renamed.
IMO Renaming this a third time will simply add more such confusion to
this area and make the "explaining" david alludes to above even longer
to add a third case to make people aware of the rough equivalency of
the third name in the saga, since the old names will not go away soon
or easily.

> 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. :-(

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Russ Housley]

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 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  > 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 > > > wrote:
>> > 
>> > 
>> > 
>> > **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

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

[Deirdre Connolly]

> 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
adoption by any standards bodies: in the -hybrid-design and
-mlkem-key-agreement documents, the `Client` generates an ephemeral
keypair, and the `Server` encapsulates to that keypair, but especially in
ML-KEM which is under consideration in both documents, the KEM randomly
sampled message `m` is sampled by the `Server` but the final
`shared_secret` resulting from `Encaps` and `Decaps` is based on computing
over the message `m`, the public key `PK` generated by the `Client`, as
well as the randomized ciphertext `CT` generated by the `Server`. The
encapsulated message `m` is not actually the `shared_secret` that is the
input to the TLS 1.3  key schedule, even independent of the entire
handshake transcript being included into the full key schedule as well.

The naming of the document excluded 'key exchange' and 'key establishment',
and went with 'key agreement', but that is a weakly held name,

On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  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  wrote:
> >
> > 
> >
> > **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

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

[Eric Rescorla]

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 not generally accurate with the KEM schemes under consideration
> for adoption by any standards bodies: in the -hybrid-design and
> -mlkem-key-agreement documents, the `Client` generates an ephemeral
> keypair, and the `Server` encapsulates to that keypair, but especially in
> ML-KEM which is under consideration in both documents, the KEM randomly
> sampled message `m` is sampled by the `Server` but the final
> `shared_secret` resulting from `Encaps` and `Decaps` is based on computing
> over the message `m`, the public key `PK` generated by the `Client`, as
> well as the randomized ciphertext `CT` generated by the `Server`. The
> encapsulated message `m` is not actually the `shared_secret` that is the
> input to the TLS 1.3  key schedule, even independent of the entire
> handshake transcript being included into the full key schedule as well.
>
> The naming of the document excluded 'key exchange' and 'key
> establishment', and went with 'key agreement', but that is a weakly held
> name,
>

I would probably rank order these as establishment > agreement > exchange,
but I'm not going to argue about these.

-Ekr


> On Thu, Mar 28, 2024 at 5:08 PM Russ Housley  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  wrote:
>> >
>> > 
>> >
>> > **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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Sean Turner]

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 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

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

[Wang Guilin]

Dear Deirdre,

Could say a little more why both 'key exchange' and 'key establishment' have 
been excluded?

>The naming of the document excluded 'key exchange' and 'key establishment', 
>and went with 'key agreement', but that is a weakly held name,

Thanks,

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 Support Group Elliptic curve groups 
space

> 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 
adoption by any standards bodies: in the -hybrid-design and 
-mlkem-key-agreement documents, the `Client` generates an ephemeral keypair, 
and the `Server` encapsulates to that keypair, but especially in ML-KEM which 
is under consideration in both documents, the KEM randomly sampled message `m` 
is sampled by the `Server` but the final `shared_secret` resulting from 
`Encaps` and `Decaps` is based on computing over the message `m`, the public 
key `PK` generated by the `Client`, as well as the randomized ciphertext `CT` 
generated by the `Server`. The encapsulated message `m` is not actually the 
`shared_secret` that is the input to the TLS 1.3  key schedule, even 
independent of the entire handshake transcript being included into the full key 
schedule as well.

The naming of the document excluded 'key exchange' and 'key establishment', and 
went with 'key agreement', but that is a weakly held name,

On Thu, Mar 28, 2024 at 5:08 PM Russ Housley 
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 
> mailto:s...@sn3rd.com>> wrote:
>
> 
>
> **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