On Wed, Nov 5, 2025 at 12:18 AM Bellebaum, Thomas <thomas.bellebaum= [email protected]> wrote:
> > > 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? > Yes. There's no meaningful way to free the registry from entries once they've been in use. All you can do is tell people not to use them. 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]. > You're making the common mistake of attributing one argument offered by a presenter with the views of the WG. The view of the WG as expressed by the consensus call is to make it "D", but that doesn't mean that the WG endorses (or doesn't endorse) that particular bullet point. 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 don't think it paints this picture. 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. > I think this would be fine. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
