On Thu, Jul 2, 2026 at 3:06 PM Orr Dunkelman <[email protected]> wrote:
> 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. > This is a reasonable position, but what your message actually *said* was that 9189 "should not have been standardized". It was not. Moreover, as I observed in my previous message, 9189 went though the Independent Stream, not the IETF, which means that it had nothing to do with the TLS WG. Even if the TLS WG declines to publish this specification, the authors will still have the option of taking it to the Independent Stream. In fact, Simon Josefsson suggested they do this yesterday. [0] FWIW, I agree that the existence of non-IETF RFCs is confusing, but nevertheless it's the situation we are in. > 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. > I do not understand what point you think this proves. I don't think I've heard anyone argue that because there is a code point we need an RFC, and all I'm saying is that the nonexistence of an RFC is not going to stop people from implementing this specification. -Ekr [0] https://mailarchive.ietf.org/arch/msg/tls/SABh7Sw1dqdv_I04WFUeQByoVVY/ 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]
