Setting aside the question of use cases for a moment, let me note that no one even bothered to ask IANA to assign codepoints for any hybrid not already listed in this I-D. I see no reason to hold up this document now: we can always publish a follow-up later on.
On Fri, Oct 10, 2025 at 9:17 AM Kris Kwiatkowski <kris= [email protected]> wrote: > It was suggested in the past (both at the mailing list and at github), > but the decision was made not to include this option since the use case > for that combination was unclear. At the same time, keeping the number > of algorithms to a minimum was considered beneficial. > > What would be the use case for that code point? > > On 10/10/2025 07:23, Viktor Dukhovni wrote: > > > On Tue, Oct 07, 2025 at 09:39:52AM -0700, Eric Rescorla wrote: > > > >> For context, there are currently four such supported groups for TLS: > >> X25519, X448, P-256, and P-384. Is there a substantive reason why the > >> hybrids of these same groups with MLKEM ought not to be RECOMMENDED=Y? > > I was just drafting a message to suggest that the draf is missing an > > obvious combination: > > > > MLKEM1024 + X448 > > > > If MLKEM1024 is supported with SecP384r1 (P-384), it should also be > > supported with X448. The supported combinations would then be more > > "natural": > > > > MLKEM768 + either P-256 or X25519 > > MLKEM1024 + either P-384 or X448 > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
