2025-01-07 14:16 GMT+01:00 John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>: > Alicja Kario wrote: > >Can you point to examples of people actually using x448 (TLS group ID 30) in > >practice? > > I think that is the wrong question.
If no one deployed X448 I don't see why they would deploy X448MLKEM1024, so I see no reason to standardize it. The reason to deploy SecP384r1MLKEM1024 is compliance. Like it or hate it. The obvious set of hybrids to standardize and implement is: 1. the one everyone should use; 2. one that everyone who can't use (1) can use. I personally liked SecP256r1MLKEM768 for (1) because I need to carry an optimized P-256 implementation for WebPKI certificates anyway, but X25519MLKEM768 is fine, too. SecP384r1MLKEM1024 fits the bill for (2) while X448MLKEM1024 does not, both for compliance transition reasons, and for "many libraries don't offer a X448 implementation" reasons. (I *also* generally disagree with ephemeral ECDH over NIST P curves being "far from the state of the art," I actually think it's perfectly fine, but we don't have to resolve that disagreement: it's not an input to the argument above.) > I think the right question is which hybrids do IETF recommend people to use > in the future. I think the answer is hybrids with X25519, X448, Ed25519, and > Ed448. > > I don't think IETF should standardize much more P-256, P-384, P-521, ECDSA, > RSA, and SHA-2. For new products, Ericsson is currently asking all our > suppliers for X25519, X448, Ed25519, Ed448, and SHA-3 and we are willing to > pay for that. P-256, P-384, P-521, ECDSA, RSA, and SHA-2 were all quite good > algorithms when they were standardized decades ago, but today they are far > from state-of-the art. > > Cheers, > John > > *From: *Alicja Kario <hka...@redhat.com> > *Date: *Tuesday, 7 January 2025 at 13:52 > *To: *Loganaden Velvindron <logana...@gmail.com> > *Cc: *tls@ietf.org <tls@ietf.org> > *Subject: *[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448 > (I originally proposed PR that added that codepoint, together with the > secp384r1mlkem1024, so I'm really not against it, but...) > > Can you point to examples of people actually using x448 (TLS group ID 30) > in > practice? > > If you want to experiment, then there's the whole private range, what would > making a public ID add to that experiment? > > On Tuesday, 7 January 2025 10:01:20 CET, Loganaden Velvindron wrote: > > How about having x448mlkem1024 allocated as an experimental codepoint > > for those who > > wish to use it ? > > > > > > On Mon, 6 Jan 2025 at 12:52, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > >> On Mon, Jan 06, 2025 at 08:00:04AM +0000, Kris Kwiatkowski wrote: ... > > > > -- > Regards, > Alicja (nee Hubert) Kario > Principal Quality Engineer, RHEL Crypto team > Web: > https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cbbc800fcb3474cec48ed08dd2f1a1b11%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638718511346705932%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dig7Bh9QRBv523MgDQnegB48hAQdcMpomAo64uZB5b0%3D&reserved=0 > 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 > _______________________________________________ > 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
