> > 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? 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
