This "seal of approval" argument appears to be the motivating issue
behind the current opposition, but I have a hard time believing it is
such a deal-breaker. Yes, there always be people who mistake
"publication as an RFC" as a "publication as a standard", despite the
clear statement that informational or experimental RFCs do not specify a
standard. This is by no means a new issue. Should a specification that
is considered problematic by some be published as an RFC? For a
discussion, see for example RFC 1796, published 31 years ago
(https://www.rfc-editor.org/info/rfc1796/). The attitude of Jon Postel
at the time was that if something was going to be used, it is better to
publish it as an RFC. It ensures that if people are going to use a
specification, they all use it in a compatible way. It also ensures that
the specification becomes highly visible. And it reduces the motivation
to develop parallel publication channels for competing standards.
-- Christian Huitema
On 7/2/2026 3:06 PM, Orr Dunkelman 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.
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]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
