Specifically the X25519MLKEM768 is widely deployed already. I'm not aware
of any deployments of the other hybrids. I am very strongly opposed to
incompatible changes to the widely deployed one for something this trivial
and unimportant.
I am not personally opposed to changes to the others if the WG wants to
make them match the widely deployed one. (Though, of course, of they are
also widely deployed in some other context, we should probably leave them
alone too.)
On Thu, Oct 17, 2024, 08:33 David Benjamin <david...@chromium.org> wrote:
> While this whole situation is indeed ridiculous (there is obviously no
> security reason to use one or the other order and any certification systems
> that believe otherwise are clearly wrong and should be fixed), this draft
> with this order is now running code in several large deployments. I don't
> think it's worth the churn just to flip this back and forth now. Especially
> as key share prediction is not yet done and widely deployed.
>
> I also agree that making the names inconsistent with each other will just
> confuse people, even if the internal orders are inconsistent.
>
> On Thu, Oct 17, 2024, 08:19 Jan Schaumann <jschauma=
> 40netmeister....@dmarc.ietf.org> wrote:
>
>> Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> wrote:
>> > The number of people that actually implement these hybrid KEMs is much
>> > smaller than the number of people that need to make a choice based on
>> their
>> > name. How do we explain that one is called MLKEM768X25519 and the other
>> > SecP256r1MLKEM768?
>>
>> "In hybrid key exchanges, the name reflects the
>> order."
>>
>> This strikes me as overall much less confusing all
>> around than
>>
>> "One is called <first><second>, the other is called
>> <second><first>, because we wanted to have both end in
>> the same string."
>>
>> People choosing will do a substring match ("I want
>> PQC, so... ok, here's one that contains 'MLKEM', let
>> me enable that.").
>>
>> -Jan
>>
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
>
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
