Hi Orr, My company has decided to remove all ISO cryptographic standards from its internal recommendations and decided that we are against their use everywhere. The reason is not SPECK, but rather our belief that paywalled cryptographic standards pose a significant security risk. I think cryptographers should stop engaging with ISO as long as the specifications remain paywalled or the discussions are kept secret.
I welcome that governments design and publish cryptographic algorithms such as B-curves, SHA-2, AES-KW, SAKKE, SIMON, SPECK, GLEVIAN, and VIGORNIAN. It is quite understandable that governments do not want to reveal design criteria related to unpublished cryptanalysis. Looking at the B-curves over 2^p and SAKKE over p^2, they were clearly better designed than many academic curves that were recently broken. I think the decision to adopt SPECK in RFID was quite reasonable. The demonization of SIMON/SPECK had a negative impact on practical security. I know companies where SIMON/SPECK was the only practical choice, yet they chose not to use any encryption, because using NSA-designed encryption was seen as much worse marketing than using no encryption. I do not think that discussions in the ISO cryptographic working group should necessarily be seen as positive. I think the recent discussion of ISO and government-designed cryptography is somewhat strange. ML-KEM was not designed by any government, does not use any government-designed hash functions, does not have unexplained design choices, and the improvements compared to Kyber had consensus on the public PQC forum mailing list. If there is any discussion to be had, it is about Bernstein’s criticism of the IETF for lack of transparency while heavily engaging in ISO, as well as his claims that ML-KEM is an “NSA backdoor”, despite heavily using the NSA-designed SHA-2 in Ed25519, SPHINCS+, and NaCl. I would like to phase out SHA-2, not because of its origin, but because SHA-3 is vastly superior both theoretically and practically. Cheers, John Preuß Mattsson From: Orr Dunkelman <[email protected]> Date: Friday, 3 July 2026 at 07:39 To: [email protected] <[email protected]> Cc: Markku-Juhani O. Saarinen <[email protected]>; [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) 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 <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> wrote: > >> >> On Thu, Jul 2, 2026 at 2:39 PM Orr Dunkelman <orrd= >> [email protected]<mailto:[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]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
