I beg to disagree. Because many people don't see the difference between them (and yes, I am aware that this is an informational RFC, and yes, there is a code point registration). In many instances people just follow the standards, RFC, ISO, ETSI, and don't care whether they are informational, mandatory, or otherwise just a standard that is there. Many people view this as a seal of approval by some standardization body. And I believe that such seals should be given less promiscuously.
I think that there is value in simplicity for security (and I think that the technical claim that simpler = better is a good point for the proposed informational RFC), yet, one cannot hold the idea that simplicity = better security, and not realize that outside IETF, once something is RFCized this is considered by many as an RFC. BTW, this just proves my point - once there is a code point registration, then now, we must have a way to "satisfy" this. On Fri, Jul 3, 2026 at 12:50 AM Eric Rescorla <[email protected]> wrote: > > > On Thu, Jul 2, 2026 at 2:39 PM Orr Dunkelman <orrd= > [email protected]> wrote: > >> Well, you are right - RFC 9189 should not have been standardized. >> > > It was not. It's Informational and It's an Independent Submission/ > > > I would guess that once there is an RFC that says this is the Kuznyechik >> block cipher (namely, RFC 7801), >> > > Another Independent Submission. > > > >> it is a bit harder to say to people - hey, this cipher, which appears in >> an RFC, cannot be used in TLS, because we found problems in the cipher. >> This is why whatever was in ISO _before_ the issues were discovered, was >> left and not removed, whereas the new stuff was not accepted. >> > > As a matter of policy, the TLS WG has a very permissive policy towards code > point registrations, essentially only requiring that you have a document. > The > rationale behind this policy is that forbidding people from having code > points > for algorithms is not an effective way of restricting their use. In > certain cases, > once the WG has decided that an algorithm is insecure we will forbid their > use (e.g., RC4) and mark them as "Recommended=D", but we don't do that > as a matter of course for algorithms that are not widely used. > > I know I'm repeating myself, but this is also the situation for MLKEM; > there > is already a code point registration. All that is being discussed here is > whether > we will publish an Informational IETF RFC specifying it. > > -Ekr > >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
