Simon Josefsson wrote: >non-NIST/MLKEM hybrid PQ KEM for TLS. FrodoKEM? Streamlined NTRU Prime? We >need more hybrid PQ options.
This makes absolutely no sense. Is Kyber (mostly developed by European cryptographers) suddenly bad just because NIST think it is good? Would you stop using NTRU Prime if it was standardized by NIST? Adding more structured lattice-based cryptography such as NTRU Prime does not add much value. Agree that registering TLS code-points for FrodoKEM from a non-paywalled specification should be done. >BSI recommends FrodoKEM and Classic McEliece, presumably leading to that >high-value attack targets in Germany uses them. To me, those count as strong examples of external vetting. Is ANSSI writing that Classic McEliece is not recommended also a strong example of external vetting? >I think it may be that is actually EASIER to add another algorithm with >similar characteristics as MLKEM, such as Streamlined NTRU Prime or FrodoKEM, >because implementers will already have resolved those similar concerns (buffer >sizes, protocol limits, API concerns etc). FrodoKEM does not have similar characteristics to ML-KEM at all. ML-KEM have one order of magnitude smaller public keys/encapsulations and two orders of magnitude better performance. I think HQC-KEM is the only reasonable algorithm for TLS WG to add as a backup to ML-KEM. It is code-based and has performance properties so that it could be used widely instead of ML-KEM. Cheers, John From: Simon Josefsson <[email protected]> Date: Monday, 24 November 2025 at 20:05 To: Eric Rescorla <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26) Eric Rescorla <[email protected]> writes: > On Mon, Nov 24, 2025 at 7:14 AM Simon Josefsson <simon= > [email protected]> wrote: > >> We are having trouble getting safe hybrid PQ solutions published. Until >> we have a couple of widely deployed hybrid PQ KEMs published, >> implemented and deployed, I don't think we should fragment the already >> thin resources we have to reach that goal by spending further cycles on, >> and then publish a fragile solutions like this. Please prioritize a >> non-NIST/MLKEM hybrid PQ KEM for TLS. FrodoKEM? Streamlined NTRU >> Prime? We need more hybrid PQ options. >> > > Why? The general deployed pattern in TLS is to have a small number of > dominant algorithms and we already have X25519+MLKEM widely deployed. > Given that any particular connection can only be protected with a single > algorithm, it's not clear to me how the world is improved by having multiple > algorithms with roughly the same performance properties. Historically, I believe we have been helped by having multiple security options available to jump between when new security problems are published. We don't know the nature of future security problems, therefor hedging by having a couple of alternatives readily available may help. There is a cost to that, but I think it is small price compared to the risks involved. > I could see some argument for having some algorithm with significantly > different performance/security tradeoff (though as I understand it there are > some practical challenges to adding Classic McEliece), but that doesn't > seem to be what you're suggesting here. I'm asking for that too, Classic McEliece can be another alternative. Given that ML-KEM has a PQ KEM monopoly here, I think almost anything we can add will be an improvement. I think it may be that is actually EASIER to add another algorithm with similar characteristics as MLKEM, such as Streamlined NTRU Prime or FrodoKEM, because implementers will already have resolved those similar concerns (buffer sizes, protocol limits, API concerns etc). That's why I picked those two. I would like to have Classic McEliece too, because for some non-web TLS applications, it offers better properties than the others. From a security hedging point of view, I agree adding something widely different make more sense (like Classic McEliece), but I don't see these as an either-or situation. > More generally I am opposed to the IETF publishing any algorithm > specification > for TLS which has not been externally vetted. That could mean standardized > elsewhere or sign-off by CFRG, but the TLS WG should not just be picking > up algorithms without external review and adding them to TLS. What do you mean by 'externally vetted'? Who to judge the quality of the external vetter? OpenSSH uses Streamlined NTRU Prime for many years, and SSH traffic is a high-value attack target. BSI recommends FrodoKEM and Classic McEliece, presumably leading to that high-value attack targets in Germany uses them. To me, those count as strong examples of external vetting. What I often see is a request like yours is pretty much the same as saying that nobody except NIST have the resources to evaluate crypto algorithms, and that we should trust them. I think that is as unwise as only trusting BSI or OpenSSH. /Simon
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
