[TLS] Re: Working group last call for the deprecation experimental code points in ECDHE-ML-KEM

[Joseph Salowey <[e-mail]>]

Thanks everyone for participating in this call.  The document will be
updated to standards track with a slightly modified text in the obsolete
section:
PR - https://github.com/tlswg/tls-ecdhe-mlkem/pull/55/files

Text for section 7.4:

Experimental code points for pre-standard versions of Kyber786 were added
to the TLS registry as X25519Kyber768Draft00 (25497) and
SecP256r1Kyber768Draft00 (25498). This document obsoletes these entries.
IANA is instructed to modify the recommended field to 'D' and update the
reference to add [ this RFC ]. The comment fields for 25497 and 25498 are
updated to "Pre-standards version of Kyber768. Obsoleted by [this RFC]"

Thanks,

Joe


On Wed, Nov 5, 2025 at 4:06 AM Filippo Valsorda <[e-mail]>
wrote:

> 2025-11-05 09:15 GMT+01:00 Bellebaum, Thomas <thomas.bellebaum=
> [e-mail]>:
>
> > > added to the TLS registry as X25519Kyber768Draft00 (25497) and
> > > SecP256r1Kyber768Draft00 (25498). This document obsoletes these
> entries.
> > > IANA is instructed to modify the recommended field to 'D' and update
> the
> > > reference to this [ this RFC ].  The comment fields for 25497 and
> 25498 are
> > > updated to "obsoleted by [ this RFC ]"
>
> To be clear: We are not freeing the registry from these entries, but just
> warn against interop problems because everyone is supposed to use the new
> code points?
>
> So the WG rejects "D" as a means to warn against non-hybrids with some
> resoning that D is only "for weak cryptographic algorithms" [1], and would
> group it "with NULL ciphers, RC4, DES, EXPORT ciphers, MD5, etc" [2].
> Yet, for some reason we are more flexible here?
>
>
> The full quote from
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-15.html#section-3,
> linked at from [1], is "*This marking could be used to identify
> mechanisms that might result in problems if they are used, such as a weak
> cryptographic algorithm or a mechanism that might cause interoperability
> problems in deployment.*" so yeah: "NULL ciphers, RC4, DES, EXPORT
> ciphers, MD5, etc" are the former, this is the latter, and pure PQ
> algorithms are neither.
>
> Anyway, I support this change. (I don't think the track of a document ever
> had any impact whatsoever on my work, so why not.)
>
> Normally I would welcome the above measures, but the picture it paints is
> that there are already some hybrids with "D" yet there are non-hybrids with
> "N", so "_surely_ hybrids are less safe", which (putting aside the
> important technical debate on this) is definitely not true for reasons of
> code point allocation.
>
> I oppose this change until the comment fields are made more descriptive.
> Something like "Concluded experiment, refer to [ new equivalent code point
> ] for standard ML-KEM" would suffice.
>
> -- TBB
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/bULX8Y0mPdmW5_d5Q5VTdupR4nY/
> [2] https://youtu.be/zTAuEx9Otys?si=5hllRBXbjkkG1E8o&t=1909
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> *Attachments:*
>
>    - smime.p7s
>
>
>