On Friday, 1 November 2024 18:02:44 CET, David Benjamin wrote:
Tangentially, this is registering a `NamedGroup` /
`SupportedGroup`, but of course it's not a group, it's a KEM
scheme over which no Diffie-Hellman of any kind can be done.
Where do IANA preallocations start bumping up against "well
we're doing something completely different anyway"?
The deciding factor for these registries isn't the names of the
fields but what the protocol does with them. If we started a new
registry for KEMs, it wouldn't be useful in TLS because TLS 1.3
specifically needs a codepoint in the NamedGroup enum.
The FFDH range isn't treated special because of naming but
because of some mistakes that RFC 7919 made where the
implementation actually needs to categorize codepoints. The
group naming is unfortunate but the last ill-advised rename from
curve to group was incredibly expensive. If we want to rename it
again, "KEM" or "KeyAgreement" or "KeyExchange" or
"KeyShareType" would have been a much better name, but given how
problematic the last rename was, I'm not very thrilled about the
prospect.
actually the FFDH range is special, see section 4 of RFC 7919:
If a compatible TLS server receives a Supported Groups extension from
a client that includes any FFDHE group (i.e., any codepoint between
256 and 511, inclusive, even if unknown to the server), and if none
of the client-proposed FFDHE groups are known and acceptable to the
server, then the server MUST NOT select an FFDHE cipher suite.
but yes, it should have been renamed then to something like
Key Exchange Algorithms, not to Supported Groups..., but like they say,
hindsight is 20-20.
See also
https://mailarchive.ietf.org/arch/msg/tls/-jYbYd7cXKIzySPp578kAsWZt5c/
David
On Fri, Nov 1, 2024 at 12:28 PM Deirdre Connolly
<durumcrustu...@gmail.com> wrote:
If there's a choice to be made I favor the 512 513 514 choices
On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly
<durumcrustu...@gmail.com> wrote:
Ah, oops!
Tangentially, this is registering a `NamedGroup` /
`SupportedGroup`, but of course it's not a group, it's a KEM
scheme over which no Diffie-Hellman of any kind can be done.
Where do IANA preallocations start bumping up against "well
we're doing something completely different anyway"?
On Fri, Nov 1, 2024, 11:47 AM Salz, Rich <rs...@akamai.com> wrote:
I made a mistake and you're right " 261, 262, and 263 are
assigne to the MLKEM512, MLKEM768, and MLKEM1024" wrong.
We'll notify IANA to pick 512 513 514 or 4584 4585 4586. Or something.
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
