Orr,

> After their lightweight block ciphers were rejected as ISO standards in
the cryptographic working group, somehow SPECK (one of the aforementioned
ciphers), became a standard in the RFID working group. Namely, by using the
fractured nature of ISO, a standard that the cryptographic experts working
in the field deemed is not trustworthy enough, made its way into ISO 29167.
Now, SPECK is indeed an ISO standard, but just not one that was decided by
experts in cryptography/security. Go and ask a random computer security
expert if SPECK is an ISO standard, and whether it should be trusted as
such.

Do you believe there's a backdoor in SPECK and/or SIMON that doesn't also
somehow implicate every other ARX-based cipher in the cryptographic
literature? If so, please tell me how you think they could even begin to
pull it off.

> The story here seems a bit similar - as mentioned before - there is a
proposal to make this a non-IETF RFC (and we are discussing
"informational", but from the outside it looks as approved by the IETF).

>From "the outside"? Which outside? What if I said, from "the outside", the
IETF looks like a toxic cesspit due to a striking lack of fursona accounts
participating in the discussion. Is that a valid perspective for the IETF
to spend their volunteer time and energy on?

The IETF can only control its own messaging, not how some unknowable
"outsiders" might ignorantly interpret it. There are informational track vs
standards track documents; the Recommended=Y/N flag; and other indicators
of whether a document has "approval". If people are not competent enough to
read and interpret a technical document, why are they doing that job
without proper training first?

Let's be abundantly clear: Why does this RFC need to exist? The answer
isn't "to replace hybrids and sneakily downgrade security". If the NSA
thought they had a NOBUS backdoor in ML-KEM, why would they be moving
everything to use it for TOP SECRET classified information as fast as they
can? That would be malfeasance on a level that is beyond parody. The answer
is far more boring.

There are some industries (namely telecoms, but certainly others that don't
come to mind) that require an RFC, due to rules that have nothing to do
with cryptography or even security.

This is a slight tangent, but please bear with me: The existing FIPS
documents do not specify how to use these algorithms with TLS. FIPS is
required to sell any product or service with any "cryptographic module" to
the US government. The US government obviously uses a lot of phones. Some
(not all!) parts of the US government will also demand CNSA 2.0 compliance,
which doesn't allow hybrid PQ-- only pure PQ. FIPS / CNSA 2.0 are not the
only game in town, but it's the one I'm (unfortunately) somewhat familiar
with.

The folks objecting to publication of this draft because they think
ECDHE-MLKEM is safer than just MLKEM (which is, I must emphasize, NOT TRUE
AT ALL after Q-Day) is a non sequitur. Like, throw new TypeError(). Their
threat model is not coherent. See
https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/ for
more.

> Now, I understand why IETF wants interoperability, but I urge those who
support this informational RFC to consider the impact this will have on
trust in other IETF RFC.

Now, I understand why IETF wants professionalism, but I urge those who
support decorum to consider the impact this will have on trust in spaces
that have adequate open participation from the furry fandom
<https://bsky.app/profile/goat.sex/post/3lbcu4yuups2u> (which is noteworthy
for its LGBTQIA+ and neurodivergent demographics
<https://furscience.com/research-findings/>).

> In the longer term you will cause people to ponder whether RFCs are
indeed "seals of approval".

They never were! RFC stands for "Request For Comments". They aren't
authoritative in the sense that they exist to end a conversation. They
provide technical specifications, protocols, and best practices for the
Internet.

And even if you treat Standards track RFCs as authoritative in that way,
Informational RFCs especially were never "seals of approval". There's
nothing lost in the scenario you are imagining.

> And while I agree that the proposed RFC will clearly be marked as
"informational", and even if you put a label saying - "hey guys, you should
really use a different method, and we only put this is here for
interoperability", or any "keep out of reach of children" warning you like,
there will be people who will lose trust in the RFC process to the point
that in the future, they will pay less attention to IETF RFC's

If this is the same crowd that's only paying attention to this RFC process
because they want to derail an informational RFC from being specified
because they believe it "enables SIGINT
<https://web.archive.org/web/20260630091949/https://mailarchive.ietf.org/arch/msg/tls/fMwZwW3E4vBEZ-8H38MgaHNMURA/>"
or believe Bernstein's dishonest mischaracterization of this RFC draft as being
from the NSA
<https://web.archive.org/web/20260630091958/https://mailarchive.ietf.org/arch/msg/tls/rKvghQtWpjlSbCkn0IIB9D2XElQ/>,
I cannot help but think, "Good. Don't come back."

> (I know that some people where so surprised with the SPECK ISO's hack,
and decided that they are not going to trust ISO standards anymore. All of
them.)

ISO has always been clown-shoes to me for the simple reason that I have to
pay them money to read what the standard even is that I'm supposed to
follow. Nothing of value is lost.

On Fri, Jul 3, 2026 at 1:39 AM Orr Dunkelman <orrd=
40cs.haifa.ac.il@dmarc.ietf.org> wrote:

> Well, let me tell you why I am worried about the "seal of approval", and
> specifically, the action of the NSA.
>
> After their lightweight block ciphers were rejected as ISO standards in
> the cryptographic working group, somehow SPECK (one of the aforementioned
> ciphers), became a standard in the RFID working group. Namely, by using the
> fractured nature of ISO, a standard that the cryptographic experts working
> in the field deemed is not trustworthy enough, made its way into ISO 29167.
> Now, SPECK is indeed an ISO standard, but just not one that was decided by
> experts in cryptography/security. Go and ask a random computer security
> expert if SPECK is an ISO standard, and whether it should be trusted as
> such.
>
> The story here seems a bit similar - as mentioned before - there is a
> proposal to make this a non-IETF RFC (and we are discussing
> "informational", but from the outside it looks as approved by the IETF).
> This will be utterly confusing, and the fact that the procedures allow for
> that, favor interoperability over trust. Now, I understand why IETF wants
> interoperability, but I urge those who support this informational RFC to
> consider the impact this will have on trust in other IETF RFC. Yes, in the
> short term you will increase the interoperability of this specific
> mechanism. In the longer term you will cause people to ponder whether RFCs
> are indeed "seals of approval". And while I agree that the proposed RFC
> will clearly be marked as "informational", and even if you put a label
> saying - "hey guys, you should really use a different method, and we only
> put this is here for interoperability", or any "keep out of reach of
> children" warning you like, there will be people who will lose trust in the
> RFC process to the point that in the future, they will pay less attention
> to IETF RFC's (I know that some people where so surprised with the SPECK
> ISO's hack, and decided that they are not going to trust ISO standards
> anymore. All of them.)
>
> Cheers,
>
> On Fri, Jul 3, 2026 at 3:00 AM Christian Huitema <huitema@huitema.net>
> wrote:
>
>> 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 <ekr@rtfm.com> wrote:
>> >
>> >>
>> >> On Thu, Jul 2, 2026 at 2:39 PM Orr Dunkelman <orrd=
>> >> 40cs.haifa.ac.il@dmarc.ietf.org> 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 -- tls@ietf.org
>> > To unsubscribe send an email to tls-leave@ietf.org
>>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>