[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

["Markku-Juhani O. Saarinen" <[e-mail]>]

On Fri, Jul 3, 2026 at 8:38 AM Orr Dunkelman <[e-mail]> wrote:

> Well, let me tell you why I am worried about the "seal of approval", and
> specifically, the action of the NSA.
>

Hi Orr & Co,

I guess we need to educate folks about what standards are and what they are
not -- that there are many kinds of standards with different caveats and
intepretations. I feel that understanding standards is one of the
foundational skills of any cybersecurity engineer. If you decide to
implement a cryptoprimitive, for whatever reason, following a standard is
very helpful in helping to make sure that the implementation is correct and
interoperable.  But an educator should never simply say "use standards"
without telling the students that there are also standards that one should
not use "by default" (one can still implement all kinds of things for
interoperability.)

Some of the conflation probably stems from the dual role of NIST in the
U.S., where it is both a standardization organization and a cybersecurity
agency. Most standardization organizations are not cybersecurity agencies
at all -- in Europe, we have a separation between ETSI-CEN-CENELEC (our 3
official std orgs), ENISA + two dozen national cybersecurity orgs, and the
executive (the European Commission).

In European terminology, "harmonised standard" means that a particular
standard enjoys a "presumption of conformity" with our regulations. By no
means are all European or international cryptography standards recommended
for use in Europe. Indeed, some standards are gradually being banned from
the market right now (practical effect of non-compliance with CRA).

This particular thing about "harmonised standards" is something that we (in
Europe) should really should try to teach to all engineering students, not
just in cybersecurity -- because the same logic applies to broader safety
and security as well. If you build, say, a fire extinguisher according to a
standard that is not a "harmonised standard", that fire extinguisher
probably will not pass a fire inspection. Building a thing like that is
fine if you're a fire extinguisher enthusiast or hobbyist, of course, but
commercially it wouldn't make much sense since people principally buy fire
extinguishers to comply with fire codes. It's the same in cybersecurity
engineering wrt CRA market surveillance (and I have not noticed much
enthusiasm for allowing "default" Chinese or Russian standard ciphers from
European authorities who decide on those things.)

On Informational RFCs -- this is the way it has always been. When I helped
write RFC 7693 on BLAKE2, I didn't think that it was some kind of "seal of
approval" (personally I usually recommend SHA3 over SHA2 or BLAKE2/3,
principally due to engineering reasons). The existence of, say, RFC 7693
just means that a specification is freely available to engineers who may
want to implement BLAKE2, for whatever reason -- typically for
interoperability. As a member of the IETF CFRG Crypto Review Panel, I
acknowledge that our review process is really quite lightweight (we are not
really expected to do cryptanalysis, for example). Again, we would need to
inform our engineering students about this.

Anyway, in the particular case of "pure" ML-KEM, I don't see credible
technical or security reasons to prevent its publication. And I see it as a
useful engineering specification, which should be published. The resulting
Informational RFC may even be referenced in a harmonised standard after a
few years, if and when quantum computers start really doing their thing and
people lose their attachment to quantum-vulnerable cryptography. So it's
good to have it availalable.

Some tangential anecdotes:

On the particular issue of Kuzneychik -- the thing with S-Boxes is a
curious one, and I, despite my best efforts (including interviewing the
designers in Russia!), never understood why they did it that way. Probably
a result of over-classification and a particular kind of counterproductive
security culture. But it is definitely on the "suspect" list and I would
not recommend its usage over other options -- but still the existence of an
informational RFC is arguably useful for Russian engineers who participate
in IETF, and for companies that built things according to that spec. So I
am not opposed to a free specification existing. On SPECK -- somehow I
actually feel that despite the lack of public design process documentation,
the later adversarial peer-review and undeniable technical merits of the
algorithm actually makes it attractive for practical use.

Cheers,
-markku
Dr. Markku-Juhani O. Saarinen <[e-mail]>


On Fri, Jul 3, 2026 at 8:38 AM Orr Dunkelman <[e-mail]> 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 <[e-mail]>
> 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 <[e-mail]> wrote:
>> >
>> >>
>> >> On Thu, Jul 2, 2026 at 2:39 PM Orr Dunkelman <orrd=
>> >> [e-mail]> 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 -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>
>