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
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
