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
