Oh I definitely agree there is a deeper problem here. It seems like NIST wrote something over-restrictive and then folks did a preemptive compliance maneuver to try to satisfy it. This is not a good way to do protocol development and hampers what should ultimately have been the goal for everyone: making TLS a good protocol to secure network communications.
But, regrettable as it is, the damage has been done for X25519MLKEM768 and we shouldn't change it now. Fixing the underlying problem is for the future. The compliance schemes should be fixed so that they reflect the actual security needs here, and there is no reason to have an opinion on whether any particular compliance scheme's preferred secrets go first or second. After all, the *entire point* of this hybrid thing is that you don't have to care about the other input. On Wed, Oct 23, 2024 at 11:39 AM Joseph Birr-Pixton <[email protected]> wrote: > On Fri, 18 Oct 2024 at 15:12, Salz, Rich <rsalz= > [email protected]> wrote: > >> To me, this trumps geek esthetics about making things line up. >> > > To be clear, my objection is not aesthetic or even about implementation > effort. My concern is about rubber-stamping whatever unprincipled things > that NIST comes up with. > > I also agree that altering X25519MLKEM768 (with the now-reversed order > compared to X25519Kyber768) would be silly at this point -- and I think > that goes probably for the name too. > > Thanks, > Joe > _______________________________________________ > 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]
