On Fri, Nov 1, 2024 at 2:02 PM Alicja Kario <hka...@redhat.com> wrote:
> 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. > Right, we're saying the same thing. The FFDH range is special because a mistake in RFC 7919 led to the receiver needing to categorize codepoints it didn't understand. Specifically, the mistake was using the same cipher suite values as the old TLS 1.2 DHE construction, where groups are chosen by server fiat and without negotiation. (That mistake makes RFC 7919 basically useless in solving the negotiation problem. See https://mailarchive.ietf.org/arch/msg/tls/mWWEJdw_SxAIlvZQnsr1_GiAhQY/ ) > 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
